-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Belongs_to relation not saved/altered when calling save() after deleting a related model [1.7/develop] #283
Comments
I was just talking with uru on #fuelphp and we narrowed the issue a littler further down: The problem of non-saved changed relations arises in my case when another relation is deleted before or after changing other relations. Sample code is as follows: <?php
// Get the record to edit from the DB
$record = \Model\Record::query()
->where('id', '=', '1')
->related('group')
->related('meta')
->get_one();
// Change the record's group according to a form input
$record->group = \Model\Group::find(\Input::post('group_id'));
// Delete the old meta-fields (this might not be best practice, but should cause the problem anyhow)
foreach ( $record->meta as $k => $meta )
{
// Unsetting the meta was added on advice from uru, but did not change the result
unset($record->meta[$k]);
$meta->delete();
}
// Then, add new meta values to the record
foreach ( \Input::post('meta', array()) as $field_id => $value )
{
// This just checks whether there is a value and if it's a valid Profilefield
if ( $value && $field = \Model\Profilefield::find($field_id) )
{
$meta = new \Model\Recordmeta(array('value' => $value));
$meta->field = $field;
$record->meta[] = $meta;
}
}
// This will change the meta fields, but will not change the group assigned to the record
$record->save(); Used models are related like so:
Even if I first change the meta-fields and then change the group, it still does not save/alter the assigned group. |
Same basic issue here :/ I have re-order all of my relationship assignments to after metadata setting to avoid this issue for now. I am using the latest 1.7/master. 1.8/develop also has the same issue. |
Grrr..... re-ordering the assignment of metadata still leads to unpredictable results. Of course, you can also avoid this by setting the foreign ids directory instead of assigning objects, but this kind of defeats the point of having an ORM. |
There were some fixes today related to this, are you using an up to date 1.8/develop? An intermediate action on the object would cause the original relation data to be reset, causing your new records not to be seen as new anymore (and therefore not saved). |
Hrm... I don't see any recent commits other than the one to classes/manymany.php. I will look out for it though! Thanks for the update. |
Ah, sorry, my bad. It was discussed today in IRC, I tested it but didn't commit it because someone else was already working on it and would send it in as a PR. Which I haven't seen yet. |
same issue here this helped me out http://fuelphp.com/forums/discussion/comment/17145 EDIT:
|
Assume two models,
\Model\Record
and\Model\Group
, with a\Model\Record belongs_to \Model\Group
,\Model\Group has_many \Model\Record
.When doing something like the following:
then
$record->group
will be changed to the new ORM-object, but the property of\Model\Record
keeping the reference to its assigned group is not updated.An exemplary result of
\Debug::dump($record->to_array());
before and after assigning the group as well as after calling save() is listed below:Before changing the group
After changing the group
After save()
If
save()
is called right after changing the group, it works perfectly, however.Using 1.6/master changes the output of the last
\Debug::dump
torel_group_id (String): "2" (1 characters)
which is the expected behavior.The text was updated successfully, but these errors were encountered: