Guess it is only valid in conditions we define for a specific relation to enable yii to choose a different alias name if they are ambigous. This was not possible in 1.1
Most probably yes. There will be dirty attributes support so it will be relatively straightforward to save related records. Currently there’s no support for it and I’m not sure if it will be in github alpha release.
In 1.1 I modified the generator so when creating a many-many instead of an if/else check depending on if it was a relation table, I just had it create both and modified the template to add a "//pivot table" comment next to the tables that were relational.
That way I get both many_many tables along with pivot table relations in case of meta data.
It would be nice to have access to both in 2.0.
edit:
Also, occasionally there’s a many_many relation where the pivot table would have
> id (PK)
> order_id (FK1, PK)
> item_id (FK2, PK)
And the relation is just through ‘order’ and ‘item’, but there’s a id as well. Would be nice if while checking if there is a many_many relation it could skip id if there were 3 pk’s. But that’s probably a fringe case.
I just learned scopes:( now I will have to re learn it haha. doh .
Looks like overall good improvements. With fewer find() methods it will be alot easier to learn yii imho, I remember it beeing very confusing "which one should I use??? waahh"
A question,
foreach(Customer::find() as $customer
Does this mean $customers = Customer::find() works to? or is $Customers::find()->all() a must?
I dont use other languages XD so for me @self sounds the most clear, after all “@me” sounds more like it’s referring to the developer…
and not to forget, we use self in yii 1.1.X today:p would make the transition smoother and it’s still very clear what it’s refer to.
I vote for @self
about @rel and @related it’s, a big HMMM. I agree with rawtaz I generally doent like shortened versions but in this case it feels like it is very clear what it refers to for most people.
I vote for @related but save me the possibility to change my mind
This new scheme of things also raises some questions:
If I load a relation using $model->relationName. the magic __get is used to load the relation getRelationName method into _related. However… What if I want to reload the data?
Isn’t a single place to define relations more straight forward? And then use __get and __set to manipulate your related data.
Note that if relations() is scrapped for the idea of seperate methods for each relationship and scope… I’m thinking of always using two different behaviors for each of my models. One for relations and one for scopes. This way, it’s more categorized imho.
If I may ask, what were the pro’s and con’s to implement it like this?
With this implementation, if I have a model with eg. 5 relations, I need to create a method for each of them. They’re also not grouped and since they look the same as other getXxx methods for custom attributes, in a list of all the methods in an IDE it can get unorganized.