On 4/25/2013 11:55 AM, Matus UHLAR - fantomas wrote: >> On Thu, Apr 25, 2013 at 1:47 PM, Matus UHLAR - fantomas >> <uh...@fantomas.sk>wrote: >>> I don't think so... IIRC the "REPLACE INTO" deletes existing record and >>> inserts new one, does not update existing. This caused some issues >>> for me >>> some ~10 years ago, so i switched to the update or insert. > > On 25.04.13 16:36, Matthias Leisi wrote: >> "REPLACE INTO" is a MySQL-specific extension and not part of standard >> SQL. > > I know, but what does this have in common with what I wrote? >
It seems that Matthias's point is that SA doesn't use "REPLACE INTO" because "REPLACE INTO" is MySQL-specific, and SA must remain database-agnostic. This leaves one to assume that SA is performing an INSERT or an UPDATE only. The question then becomes, why is SA attempting to perform an INSERT (and failing with a duplicate key conflict on the PRIMARY KEY, which, in my moderately stale version of SA, is a UNIQUE key across the `id` and `token` columns) when it should be performing an UPDATE? (Possible explanation two paragraphs down.) Presumably, the `id` column is a foreign key to the `bayes_vars`.`id` column, which indicates that only one record for each SA Bayes user and token combination may exist. Sounds reasonable. My understanding is that it's better (with respect to performance and atomicity) to attempt the INSERT and have it fail than to check if the ID/token combination already exists and UPDATE it if it does. In other words, I'm not sure that this warning is a problem (beyond log bloat or similar). It's entirely possible that SA *only* performs INSERT statements for the reasons I mention above. Only a developer or disciple of the SA source code can say for sure. I wish I had time to look myself. Out of curiosity, how did this SQL error come to your attention in the first place? -Ben
