i just figure out that i cant assign arrays of other ActiveRecords into Active record even if all relations are defined.
example
MODEL =
Class POST ... {
public function relations()
{
// NOTE: you may need to adjust the relation name and the related
// class name for the relations automatically generated below.
return array(
'tag' => array(self::MANY_MANY, 'Tags', 'tagslist(post_id, tag_id)'),
);
}
then the usage
$p = new Post;
$p->tag = array(Tag::model->findByPk(1),Tag::model->findByPk(2),Tag::model->findByPk(3));
$p->save(false);
all saves with out any error … but table tagslist is empty, how come?
then is it possible to request it as a feature, its realy annoying to add it manually very single time, not working only saving, but even if you add array of supposed objects its looks fine.
This is an often requested feature. But i doubt it will ever be implemented. The reason is, that the implementation would add way too much overhead to relational AR if it should really be useful. It might be easy for some simple cases but related records can become really complex. You need to consider a lot of edge cases. Think for example of a MANY_MANY relation where you query only a filtered subset of the related records. Then some of these records are removed others are added. What should hapen on save()? Delete all others? What about new records with duplicate Pks that where not contained in the filtered result but do exist in DB? And there’s much more of these. In my opinion it obfuscates things way too much, than what it’s worth.
There was a similar feature in PRADO’s AR implementation once (Yii’s predecessor) which was removed after some time for good reason. I still have some old code, that relies on that feature and it’s really obscure and hard to understand what’s really happening with the related records.
Saving related records is a matter of a few lines of extra code. The developer still has full control of everything and it’s easy to understand this code even after years.
you saying that it wont ever be implementing by some complex reason or its just happened to be complex and no one figure out how to do it for intuitive use?
the thing is im using AR in already Relational structure with hard-rules (on delete, cascade), so using MANY_MANY feature wont be problem.
when add MANY_MANY array() should recursively save only presented records in manner of "INSERT_IGNORE" that i was asking some time ago, sub_data and fill up look up table,
that pretty much it.
Im forced to implement this feature in my project if my code will satisfy then it will be nice.
It’s this “some complex reason” for which i tried to give an example above. I prefer having a fast and slim framework instead of a bloated, heavy one that tries to think for me (and probably still fails in the tough cases).
I wonder, what’s so hard in saving related records manually that you want this task automated? Again: I can’t think of any only slightly more complex scenario where this won’t get confusing soon and you won’t be able to tell, what’s happening behind the scenes.
in my vision MANY_MANY should create state in data that include current array as well,(besides that some how others get there for any reason) if you need to modify all set then its comes model for that look-up table
LookUpModel::delete, for conditions delete should be more explicitly,even with a relations are evolved,in some time later will be possible to create deleteRecursive();, im need that eventually.
scenario for manual managing records and relations inserts/deletes in project is project has 50 ententes in 120 different tables and writing basically same logic for each entente of is amoral to oop and programing in general.
about bloating and heavy things, end-user should never see more save(),delete(),synchronize(), for model no mentioning that if is possible to have array of other model they should be saved,deleted, an synchronized as well by just idea of what should happen when you make actions to any object simple or complex.
