Incorrect use of db_query in memcache.db.inc
| Project: | Memcache API and Integration |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | nicholasThompson |
| Status: | closed |
There are a number of cases where the table is being subsitutude into the query using the string replacement rather than directly inserting it into the string. Although technically this makes the table variable safer, it actually breaks table prefixing functionality.
Example...
<?php
db_query("SELECT data, created, headers, expire, serialized FROM {%s} WHERE cid = '%s'", $table, $key);
?>So, what happans? Drupal's db_query initially does all table prefixing by replacing {*} with prefix_* - this means the table being selected looks like this 'prefix_%s'. Drupal then replaces %s with the first arg, $table... so we get 'prefix_example_table'. Perfect! Oh - what happens if we specifically told drupal to use 'foo' as the prefix for the table 'example_table'? Well Drupal replaces {%s} and looks up what prefix should be used for '%s' - which doesn't match 'example_table' so it uses the default. '%s' then gets replaced with the table name.
The solution is to revert those queries back to the way Drupal does it by default...
<?php
db_query("SELECT data, created, headers, expire, serialized FROM {". $table ."} WHERE cid = '%s'", $key)
?>Simply shoving the table name right into the query string solves the prefixing issue at the expense of putting a variable straight into an SQL statement.
| Attachment | Size |
|---|---|
| memcache.db_.inc_.patch | 2.68 KB |
#1
Looks good to me. Thanks.
#2
I missed one and have just spent the last 6 hours debugging it!
Basically, where memcache was doing...
INSERT INTO {$table} (data, created, expire, headers, serialized, cid) VA...It should have been doing:
INSERT INTO {".$table."} (data, created, expire, headers, serialized, cid) VA...The problem with the first one is that PHP sees the curly brackets as a kind of "escape" for putting the variable inside the string and so PHP removed them. This completely stopped drupal prefixing any cache tables!
EDIT:
See this for more information on why this happened...
http://uk3.php.net/manual/en/language.types.string.php#language.types.st...
#3
great work. let's get this in.
#4
Commmited
#5
Automatically closed -- issue fixed for two weeks with no activity.