See #299888: Drupal 6 port for previous discussion about this that effected the Drupal6 upgrade path. In general, the current solutions are not idea. What other options are there?
To continue the conversation where we last left off --
From Pacmkr:
Thats freaking sweet. I will integrate as soon as I get a chance! I'm a little deep right now, we have an important release schedule for the end of the week.
I just had a revelation though; been hacking away at modules. What if we...
function really_nasty_module_db_rewrite_sql( $query, $primary_table, $primary_field, $args ) { // Set $nasty_increment and $nasty_offset in your settings.php global $active_db, $nasty_increment, $nasty_offset; mysql_query( 'SET @@auto_increment_increment=' . $nasty_increment, $active_db ); mysql_query( 'SET @@auto_increment_offset=' . $nasty_offset, $active_db ); }I'm sure there is a more appropriate hook as well. This isn't "technically" hacking the core, just exploiting the procedural nature of Drupal. =)
We can package that manure of a code in a custom module, perhaps with a more appropriate hook... and viola you can distribute this as a module versus as something that has "please hack core" instructions on it.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | auto_increment.tar_.gz | 697 bytes | nick.dap |
Comments
Comment #1
nick.dap commentedsubscribing
Comment #2
ceardach commentedAlthough it's a humorous module, I'm really curious if it'd be helpful to avoid hacking core: http://drupal.org/project/kitten
Comment #3
nick.dap commentedHmmm. How about hook_boot?
I'll try that out. I'm also reviewing our merge process starting tomorrow. The last merge was hell, doesn't scale at all. I now ALWAYS get merge errors that I have to resolve manually. Is that the case with you? How much manual conflict resolution do you normally do using your module?
Comment #4
nick.dap commentedJust to clarify. All we need to do for the "hack" is to run a simple query against the active database connection before anything is inserted into the database. Technically we don't even need to use the php function mysql_query, we can use drupal's own db_query.
hook_boot might do the job. To use the earlier example:
Comment #5
nick.dap commentedIt actually works! =D
Working against our development version, CCK (not heavy though), views, our custom modules, feedapi, etc.
Control casesJust refreshing the front page and looking at the logs.
No hack and Auto Increment module disabled:
Core hack. Auto increment module disabled.
Auto Increment module enabled. Basic testing.My settings.php
Anonymous user. Auto Increment module enabled.
Logged in as Administrator. Auto Increment module enabled.
Logged in as Administrator. Cache cleared. Auto Increment module enabled.
I also enabled all modules and refreshed the page. It looks like I hit the cache, so UPDATE and INSERT on the cache table got in before the SET statements, but the cache table does not have any auto_increment columns.
As you can see no auto_increment insert statement hits the database before our SET queries. Hence, based on this limited testing, it looks like we're safe.
Comment #6
hefox commentedSounds like auto increment would be in drupal modules, where as dbscripts is installed outside the drupal install usually.
if you're still interested, why not submit it as a drupal module then I'll edit the readme/etc. to mention it?