Nesting support & Automatic join?

[hailwood]

Nesting support & Automatic join?

[calebporzio]

So, I haven't battle-tested nesting, but I actually have a nested setup in the current app I'm working on, and it's totally working as expected. If I run into any gotchas, I'll update the package of course.

If I understand correctly, you are saying you would have a users table, a User model, then a child Admin model. You need more data for admin's, so you have a admins table that is joined the users table row?

If I have it right, is that not just a polymorphic relationship? Let me know if it differs and we can talk more about it. Just can't wrap my head perfectly around it at the moment. Thanks!

[pvledoux]

I'm joining @hailwood on that feature request. In my case I have to deal with a legacy DB where I have an objects table containing general data (let say a status column, version,...) alongside a object_type column, and children tables like posts and videos with more specific data.

objects

object_id	object_type	status	version
10	video	1	1
11	post	0	1
11	video	1	2

(just to add some salt it's a composite key object_id - object_type)

videos

object_id	title	body
10	My video title	Lorem ipsum dolor sit
11	Second video	Blabla

Currently I have a very hacky way of doing the join between the table with a scope:

class ObjectScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        $builder->join('objects', 'objects.object_id', '=', $model->getTable() . '.object_id')
                ->where('objects.object_type', '=', $model->getMorphClass());
    }
}

And I use polymorphic relations too, but I'm really not a fan of the scope solution. Your method looks really more robust, but I still need a way to do that join.

It would be cool if I could do a Video::first()->status or a Object::find(10)->title transparently, and even cooler if I could do a $video->status = 0; $video->save();

[calebporzio]

Interesting - yeah that totally clears it up. Basically it's polymorphic relationships except the morphed classes inherit from the morphTo?

[hailwood]

Hey @calebporzio,

it certainly can be accomplished via a one to one relationship, doesn't even need to be polymorphic hence the additional data would be loaded via $modelInstance->meta->admin_only_column or similar (assuming the relationship was called meta). But that also requires me to setup another model for each child model that has it's own data, so we'd have User, Admin, AdminMeta...

I was just thinking it would be cool if using this setup any data on the child table was automatically merged in with the data from the parent table to create the final entity such that we could have

users

id	email	password	name
1	[email protected]	...	Test User
2	[email protected]	...	Admin User

admins

id	admin_only_column
2	admin only value

The package would then execute

SELECT "users"."*", "admins"."*" FROM users WHERE "users"."id" = 2
JOIN "admins" ON "users"."id" = "admins"."id";

Allowing me to use $modelInstance->admin_only_column

This is also useful in the event of say an admin only relation as I'd be able to use $modelInstance->relationName rather than having to do $modelInstance->meta->relationName.

Again, just ideas :)

[calebporzio]

Ah, thanks for clarifying. It's an interesting idea. I don't want to widen the codebase without a compelling use case, and enough people that want it though. Let's keep our eye on this feature.

[gijsbeijer]

This would be great! (And exactly what I'm looking for at the moment :) ). I'll keep watching this!

[calebporzio]

Hey @gijsbeijer - mind sharing your use case? If we get enough compelling use cases in here, maybe we'll implement it.

[gijsbeijer]

@calebporzio Off course!

I'm making a website that implements papers/vacancies/news sections. All of these have a lot of similar fields. They could all be named an Article, but all of these types of articles have specific fields that should not exist on the other types.

In OOP I would say I'd create a (for example) Vacancy class and Extend that from the Article class. To keep things clear I'd also want to have the same structure in the database (e.g. an articles table and a vacancies table).

Using your package I was able to extend the class keeping the functionality of the parent class. But if I could extend the attributes retrieved bij eloquent with the ones of the child class (and it would also handle the writing part) this would be great and we could leverage OOPs extending really gracefully.

Hope this answers your question!

[gijsbeijer]

Basically yes :)

[nowendwell]

Jumping on the bandwagon here to stir up some thought.

In my use case, I could easily do direct relationships but I would like to do nested relationships just to keep the concepts clear to other devs working the projects. The middleware is setup this way so I would like the inheritance to follow suit.

User extends Model (the client)
Staff extends User (employees)
Admin extends Staff (higher level employees)

Like I said, I could easily just make Admins extend the base User but I think it would be cleaner this way.

[kverstae]

Any advancements in this new feature? I would also be interested in using something like this.

I have a lot of models that are very similar to each other, but also have some unique data attributes.
The problem could be solved by using a schemaless column (https://github.com/spatie/laravel-schemaless-attributes) and just add the differences in this column.
The problem is that I would like to add foreign keys to some of these unique attributes to ensure data integrity.

A feature like this would clean up the codebase and make it easier to work with.

[mattstauffer]

Hey friends! The team at Tighten has taken Parental back over and we're re-opening the issue tracker, but to give us a clean slate, I'm going to close all old issues that remain from when Caleb closed the issue tracker in 2020. If this is still an outstanding concern with the latest version of Parental, please feel free to open a new issue referencing this one.

Thank you!