-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
Save a cloned row updates the original one #7544
Comments
This is not surprising since all original rows attributes and fields including |
it depended from unique validators and primary keys |
Primary key value is the same in cloned instance as in original so the behavior is expected. |
The problem described above is twofold.
@lynicidn, the primary key column (autoindexed) has been excluded from the list of attributes to be saved. I didn't made it very clear in my example. The |
@twiNNi there's ID and it's not empty. Do you exect AR to ignore it? |
@samdark, I did some more tests and figured out that the model update, insert and save statements for the a cloned model creates sql commands containing only changed attributes. The parameter 'attributes' within these statements is just an additional limitation and not the list of attributes you want to see in the sql statement! As a cloned model has no changed attributes only my modified column The decision between insert or update for an `save Now its clear why my first example Everything what happend can be explained but is far away from what one would expect. I see some ways to solve the situation but all of them requires some design decisions. Maybe the sipliest one would be to see a clone as a new model and to set attributes like Ingnoring of id's (I assume your're talking about keys) could make the clone process less transparent as there could by compound keys and unique indexes. I also don't see how this could solve the problem. If you're not going to implement the suggest changes you should at least place a big warning into the doc's. |
I don't think it's really expected behavior from PHP perspective, especially cleaning out primary key value. @yiisoft/core-developers opinions? |
@samdark, I haven't asked for cleanig primary key values but to treat a clone as a new data (model or row). Managing key values should be the task for the application developer. As mentioned before there might be compound keys and unique indizes as well which need also to be considered. One additional comment: Assume you change the internal procedure how to figure out if a active record is a new one by reading the row (with modified keys) again from the database then the result is different. |
Cloning a record should be possible by doing the following: // assuming id is the primary key attribute
$model = User::findOne(1);
$model->isNewRecord = true;
$model->id = null; // set to another value if it is not auto incremental key
$model->save(); |
hm $user = User::findOne(1);
$model = new User([
'attributes' => $user->getAttributes() //id not in rules or set params - getAttributes(['username', 'email?', 'other'])
]);
$model->save(); |
cloning with uniq columns it do bug's |
as idea create |
@cebe, this works perfect. @lynicidn, your idea works also very well. Just the syntax is a bit different. $user = User::findOne(1);
$model = new User(
$user->getAttributes() // get all attributes and copy them to the new instance
);
$model->id = null;
$model->save(); Thanks for your answers. |
In the commen of "cebe" of 4 Mar 2015 he wrote:
For me this "$model->id = null" didn't work. I had to write unset($model->id) and then it worked |
I cloned a row, altered a value in a column and saved the cloned row.
Instead of inserting this row the original row was updated. Is this the expected behavior or is this a bug?
Calling the insert function also doesn't work because the columns in the new row aren't marked as dirty. So they will not be saved to the table.
The text was updated successfully, but these errors were encountered: