Copy problems - followup

[lcollong]

Interesting thread.
I had to write my own script to handle the copy function about 2 years ago for this reason. The Fabrik's method wasn't copying joined records.
I added a basic mechanism to verify the id of the newly created record in the maint table. As it seems the getLastInsert method does not guarantee that the returned id of the newly created main record (copy) has this id in case of someone else create a record exactly on the same time frame. Thus I needed to be sure to not link the joined tables to the wrong id. This site is on production (almost 8000 records created or duplicated since there) and yesterday, for the first time, the message show up indicating something went wrong during the duplicate operation. And indeed, after verification, two records have the same date of creation from two different users.

So my question. Is the Fabrik's copy record method guarantees that the joined tables will always been joined to the right main record in case of simultaneous operation on the tables ?

 

[Bauer]

After writing and testing, I just modified 4 files and put in pull requests at Github for changes that add an option in the list copy plugin so you can enter a list of columns/elements that will get reset to their default value when a row is copied.

 

[cheesegrits]

So my question. Is the Fabrik's copy record method guarantees that the joined tables will always been joined to the right main record in case of simultaneous operation on the tables ?

As far as I'm aware, yes, we can guarantee that. We use the J! database API insertid() method, which uses PHP's built in function, which depends on your database driver, but typically mysqli_insert_id, which guarantees you get the last insert ID on that connection. From the PHP manual:

The ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENT value generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.

And we grab the insert ID as the very first thing we do after inserting / updating a row. And we always use our own connection, we don't use the "common" J! one. So no other code runs on our connection. And even if two people copied on the same list at the exact same time, to the millisecond, and the processes time spliced such that it went process 1 write, process 2 writes, process 1 gets insert id, process 2 gets insert id, they wouldn't step on each other, as they are different connections.

I've never run across a case where we picked up the wrong insert ID, in all the time I've been developing and supporting Fabrik. It's obviously something which is fundamental to Fabrik's operation, and the code is pretty much bullet proof.

So I'm not sure what happened in your example, but it wasn't insert ID related.

-- hugh

 

[lcollong]

Thanks for the explanations. I'll review my code first and see if I need your advice on it.