Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
drupal_write_record() calls drupal_get_schema() which tries to load the schema from the cache. But this will fail if you run drupal_write_record() on a non default connection to a different database:
db_set_active('my_connection');
drupal_write_record( ... );
db_set_active('default');
In this case drupal does not find a cache entry on 'my_connection'. This causes drupal to try to write the schema into the cache using 'my_connection' which leads into errors because there are no cache tables.
Comment | File | Size | Author |
---|---|---|---|
#7 | drupal_write_record-1-D6.patch | 746 bytes | claudiu.cristea |
#5 | drupal_write_record-D6.patch | 815 bytes | claudiu.cristea |
drupal_write_record_on _non_default_connection-6.x.patch | 570 bytes | mkalkbrenner | |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commenteddrupal_write_record() relies on the schema. As a consequence, it can only work on the default connection.
Comment #2
mkalkbrennerIf the schema is already in memory drupal_write_record() works well on different connections if you integrate tables on different databases into the schema:
Is it documented anywhere, that this is not allowed?
I already saw a lot of custom modules that integrate legacy databases into drupal that way or move some tables into a different database due to security reasons. The only problem is drupal_write_record() when nothing else loaded the schema before using the default connection (which happens in most cases). The problem also seems to not occur if you use a non database cache.
An other solution might be a workaround in those custom modules like described here:
http://drupal.org/node/372308#comment-2442664
Comment #4
claudiu.cristeaIMO this is a bug. All database API functions must work regardless if they use the Drupal main connection or other connections. Why
db_query()
works anddrupal_write_record()
not? What is the logic? There's no explanation...The proposed patch seems to fix the issue with some changes. Here's a quick review
Use Drupal standards on comments. http://drupal.org/coding-standards#comment
Use a more appropriate name for the existing connection. Maybe
$current_db
(instead of$db
).If the current connection is
"default"
(most of cases) it seems to me thatdb_set_active()
returns"default"
not an empty string. The if check should be:if ($current_db != 'default')
. This need to be double checked at http://api.drupal.org/api/drupal/includes--database.inc/function/db_set_...Change to:
db_set_active($current_db);
Powered by Dreditor.
Comment #5
claudiu.cristeaHere's a new patch based on #4 comments.
Comment #6
claudiu.cristeaA workaround, without patching (but not safe enough...):
This is not 100% safe. A cache clear may occur between
drupal_get_schema()
anddrupal_write_record()
.I think committing the patch will make
drupal_write_record()
usable also for other DB connections. Of course tables must be created with Schema API... but this is true also for the main database.Comment #7
claudiu.cristeaHere's a better patch. Moved schema check after reverting back to the current DB connection. This assure that we wont leave the function without switching back to the current connection.
Comment #8
Damien Tournoud CreditAttribution: Damien Tournoud commentedSee #1.
Comment #9
subu.purohit CreditAttribution: subu.purohit commentedHi all,
Can I use drupal_write_record() function from a simple php script file. I have to run a php script which updates my node_revisions table. I can not add this code into .module file (within drupal
structionstructure) to avoid extra load because script is very heavy.My php script exists in my project root folder and I have included "includes/common.inc" and "includes/cache.inc" but now it is giving error for undefined "variable_get()".
Should I keep adding these inc files or it is not possible to use drupal_write_record() from outside drupal ?
Thanks in advance.
Comment #10
JeremyFrench CreditAttribution: JeremyFrench commentedI'd say that this should at least be mentioned in the documentation.