I was messing with a temporal model and noticed that when I forge a new instance of one with an ID that already exists in the corresponding table, and then save it, it stores it in the table without a problem. I know this is expected behavior of the database since the primary key is id, temporal_start, temporal_end and the temporal_start would be different for this new instance. But i was wondering if the temporal model itself was expected to just let it happen or if it should have stopped it since that ID already exists in the table.
Notes:
I'm talking about forging new entries, not finding an existing one, making a change, and saving it back.
The id in my model is not being auto incremented and I am setting it manually via passing it in with the array of data to the forge function.
I'm not sure, I've never really used it myself. Since ID in itself isn't a unique key, technically it is no problem to let this happen. But I understand why you ask.
Probably the simplest solution is to create a UNIQUE index on id, so you can't do it anymore.
The alternative would be to do a SELECT on every INSERT, which is not an optimal solution either.
I considered the UNIQUE approach, but wouldn't that stop the model from creating new entries when you do an "update" since updates for a temporal model instance are basically just new entries with a different temporal_start time as well?
Running a SELECT / Temporal_Model::find() to see if one exists before an insert isn't exactly ideal but might be the only way to make sure.
Hmm... yeah, true. Shows I'm not an expert on Temperal models. ;-)
You could extend \Orm\Model\Temporal, overload the save() method, and do your check there in case of static::is_new() ? Then it would be transparent for your app...
Donate
