I can't comment on this history, but I think I understand why the LOCK/REPLACE/UNLOCK was done. The reason is to insure that the sequence you got has not been updated by someone else, hence the REPLACE was enclosed in a LOCK/UNLOCK. All this is not needed if we use AUTOINCREMENT fields, which as someone else said, is available in the two supported databases, and even in MS SQL should someone need it in the future. This leaves only two other places where the tables are locked (one is variable_set() and the other is cache_set() which are in bootstrap.inc). On 9/28/05, Gerhard Killesreiter <killesreiter@physik.uni-freiburg.de> wrote:
On Wed, 28 Sep 2005, Robert Douglass wrote:
Moshe Weitzman wrote:
As for Gerhard's original question, it would certainly be nice to get rid of the requirement on LOCK TABLES permission. That has bit me before shared web hosts. Maybe we should use different locking technique depending on the table type or permission level of the DB user.
That bit me on a managed server (strato.de) One would think that if you've got the entire server, managed or not, that you could count on these features being there. I had to move the project to a root server because of LOCK TABLES.
I've searched a bit about when and why we introduced locking in the first place:
http://lists.drupal.org/archives/drupal-devel/2002-08/msg00222.html http://lists.drupal.org/archives/drupal-devel/2002-09/msg00087.html http://lists.drupal.org/archives/drupal-devel/2002-08/msg00243.html
It still does no explain why we need(ed?) to have the ID before the commit. Does anybody recall this?
Cheers, Gerhard