Re[2]: [PEAR-DEV] Alternative MySQL PEAR DB sequence behavior

On Sunday, July 22, 2001, 10:22:00 AM, in message "[PEAR-DEV] Alternative MySQL PEAR DB sequence behavior", Tomas wrote: TVVC> "Stig S. Bakken" wrote: >> >> Oleg Rekutin wrote: >> > >> > It also backwards-compatible, as it cleans up the garbage from the old-style >> > sequences (otherwise UPDATE fails), so that nothing has to be done on the >> > part of the user when the new mechanism is used. In addition, since the new- >> > style sequences use the same tables w/ an AUTO_INCREMENT id, it is also >> > backwards-compatible in the sense that if the user downgrades to the old- >> > style mechanism or moves the DB & application to a server with an older >> > version of PEAR DB, everything should still work (it will just keep on >> > inserting values). >> >> I've committed this patch now, and it works fine except that the first >> id returned seems to be 2? At least in the case of >> DB/tests/mysql/005.phpt. Any ideas? TVVC> It seems that INSERT INTO ${sqn}_seq VALUES(0) in createSequence inserts TVVC> the value "1", so update always get at least value 2. Should I change TVVC> the test? Yes, that's exactly why. Because, for backwards compatibility (both ways), I left the ID in the table schema as AUTO_INCREMENT, so inserting '0' (which ends up being the same as inserting '1') always results in the nextId retrieving '2'. I guess I can make a patch that doesn't request a nextId after a sequence is created, but returns a '1' right away. TVVC> Tomas V.V.Cox TVVC> PS. I've commited the new version of the patch Oleg send me time ago Great! SSB> If there are any race conditions in the conversion from old to new SSB> sequence (mysql implementation), I guess a table lock or something SSB> should be applied? Yes, good idea. I'll try to make a patch for that too. - Oleg