Repository navigation
Static relations #17
Description
Currently relationship definitions in AR are defined as non static getters. In reality an AR class represents a table and an instance of that class represents a record.
Relations are defined at the table level, but because AR uses non-static getters our query classes need to instantiate a dummy model for greedy queries.
Requirements for AR relationships:
- One definition for lazy and greedy loading
- Support (cached) retrieval via magic getter
- Support getting a query object (currently via the getter that defines it)
Pros of current approach:
- Uses "native" magic getters (with a small extension)
- Has code completion for the getters since they are normal functions
Cons:
- No way to get the relationships without instantiating a dummy model
- No way to enumerate relations
In Yii1 we had a single function defining the relationships but we also had the dummy model due to lack of late static binding. This allowed for enumeration but had other down sides.
What if, in Yii3 we try to get the best of both? Suppose we define relationships as static functions:
public static function relatedCustomers()
{
return Has::many (Customer::class, ['id' => 'customer_id']);
}Internally we would have a sound definition of the relationship, from this we can:
- build a lazy query
- build a greedy query
- enumerate via reflection
From a consumer point of view nothing changes:
getCustomersvia__invoke()->customersvia__get()
Pros:
- Relations are now static
- No need for dummy instances
- OO definition of relationship unrelated to the query object
Cons:
- no auto complete for the getter, so could require additional annotations.
- breaks BC
Activity
SamMousa commentedon Oct 28, 2018
This issue is to collect different point of views so please provide yours!
samdark commentedon Oct 28, 2018
getCustomers()and->customersare currently different. That isn't explicit.SamMousa commentedon Oct 28, 2018
_ 2. Would become more explicit when we get resolvable properties in core.
Some other thing we lose with my proposal is things like forcing joins in a relation, not sure if that is something people do?
Is there anything in the current query object that you can't or shouldn't be doing in a relation?
samdark commentedon Oct 28, 2018
Do you mean
joinWith()? Why?Nothing I can think of immediately.
SamMousa commentedon Oct 30, 2018
I'll try to work on a simple PoC
SamMousa commentedon Nov 6, 2018
@samdark could you move this to
active-record? All these repos still taking a bit of getting used to :-/Insolita commentedon May 10, 2019
+1 for this idea
Current realization of relations has a big disadvantage - it make not possible to detect existed model relations without it loading, and also internal relation inspecting is very complex. In yii1 we have explicit relation definitions belongs_to, has_one, has_many etc. At now even we get relation by name, we can't explicitly understand what kind these relation - hasOne relation definition is same as has_one and belongs_to. We must also check primary keys. If query has "via" definition, we can't explicitly understand is these classical junction, or "through" relation. Firstly it make harder to build some abstract admin solutions in django-admin style or gii genearation with better relation-based ui desicions
And generally work with relations looks difficult https://github.com/la-haute-societe/yii2-save-relations-behavior/blob/master/src/SaveRelationsBehavior.php
In issues i see feature requests for some features from eloquent like sync junction relations or polymorphic relations support, and as the fact - in eloquent relation definitions store more information https://github.com/illuminate/database/tree/master/Eloquent/Relations