as like as cache.inc and cache-install.inc, i would also hope to make variable_get/set function during installation. is it possible?
this is all because Oracle/DB2 database driver will try to write some trimming information into table variable (e.g. according to max. 30 character limitation in column/table/constraint naming under oracle), for forward and reverse mapping. it is now implemented within database driver internally, which will greatly reduce overall performance.
some pre-requirement of the feature request: variable_get/set should be function as normal, during installation. this means that variable_set() should first cache information before table exists; than write save those cached value into table after it is existed. before table exists, variable_get() should also function as normal.
Comment | File | Size | Author |
---|---|---|---|
#8 | drupal-6.x-dev-variable.inc-0.4.patch | 1.53 KB | hswong3i |
#6 | system.schema.patch | 1.61 KB | bdragon |
#4 | drupal-6.x-dev-variable.inc-0.3.patch | 1.49 KB | hswong3i |
#2 | drupal-6.x-dev-variable.inc-0.2.diff | 5.83 KB | hswong3i |
#1 | drupal-6.x-dev-variable.inc-0.1.diff | 5.78 KB | hswong3i |
Comments
Comment #1
hswong3i CreditAttribution: hswong3i commentedjust a very simple implementation that split variable_get/set/del away from bootstrap.inc, and include required version based on requirement. for installation stage, we will include variable-install.inc for special handling; after that, we will reuse normal version for better performance.
i guess we can do it in some better way, hope someone may give me a hand about this :)
P.S. as i am going to add more cache/variable handling within Oracle and DB2 driver, this issue can greatly improve their performance :)
Comment #2
hswong3i CreditAttribution: hswong3i commentedbug fix and feature add version: don't do any INSERT/UPDATE for individual variable_get/set/del, but handle overall update by
register_shutdown_function('_variable_install_shutdown');
. tested with MySQL and seems all fine :)P.S. little drawback: as variables are not write into table when calling variable_get/set/del, but delay until session close, it seems to be concurrent problem if we have duplicate call to variable_get/set/del from another session... BTW, we are using variable-install.inc during install only, seems this should never happened :)
Comment #3
hswong3i CreditAttribution: hswong3i commentedhope to detail more information about the needs of this patch.
first of all, most database come with very harsh maximum characters limitation with table/column/constraint/index naming, e.g.
this will become a critical problem for CCK and Views, or other modules which will dynamically generate table schema, as they usually use combine keys as naming format. on the other hand, this will even become a problem for core modules, since we are using combine keys as constraint/index naming, too.
my solution is very simple: create a mapping table for long-to-short and short-to-long mapping. the procedures includes:
by using this method, we can simply ignore database specific limitation: database driver will handle this mapping internally. we trade some performance (e.g. setup and use mapping), but grain a better compatibility.
BTW, the conflict is very simple: most mapping will set up during installation (during table creation) by using variable_get/set, but what will happen if table "variable" is not yet ready? variable_get/set don't expect to due with such case, therefore it will:
this patch introduce an ability to variable_get/set, which cache information before table "variable" exists, and write all cached information into database before session close. for installation, this session will be closed when all tables are successfully created, which means table "variable" is already existed. on the other hand, variable_get/set (special version for installation) will still functioning as like as normal.
Comment #4
hswong3i CreditAttribution: hswong3i commentedapproach by an opposite direction: if we only need table "variable" for storing information used for overcoming database specific limitation, so why don't we create this table before all other tables? the patch is now trying to solve the problem by this method. it is tested with Oracle, and prove as functioning :)
BTW, some conflict can never be solved: length of table prefix is still limited by length of "variable" and its primary key (e.g. pk_variable in case of Oracle). this is because we can never use a mapping to serve the name of "variable", if information is storing within it. anyway, this is just similar as case before, so just simply forget it :)
Comment #5
hswong3i CreditAttribution: hswong3i commentedthis patch just simply change the table creation sequence during installation: first create {variable} table before others, and so variable_get() and variable_set() will able to function though the rest of installation. Oracle/DB2/MSSQL driver will make use of this change, in order to overcome size of constraint naming limitation.
patch in #4 can still apply to CVS HEAD. It is tested with both MySQL/Oracle/DB2 and all passed :)
Comment #6
bdragon CreditAttribution: bdragon commentedPatch needed rerolling. Also I changed the comment a little.
Comment #7
hswong3i CreditAttribution: hswong3i commentedi guess this patch is simple enough and able to be commit with no question. it should be RTBC
Comment #8
hswong3i CreditAttribution: hswong3i commentedpatch via latest CVS HEAD
Comment #9
Gábor HojtsyOK, let it be. Committed.
Comment #10
(not verified) CreditAttribution: commented