Barry, You're indeed correct in evaluating the change and understanding the question: this was necessary because of the stringent FB limitations on the width of indexes, and is an example where a given DBMS cannot be used to port Drupal "as such" without an actual DB abstraction (instead of a DB API abstraction as we have currently). The hook_schema_alter is interesting/perplexing, BTW. I wonder where this could take us. More generally, as you say, such ports would need the specific module to be patched, instead of having a function implementing the change in the DB indendence layer, which looks like a Bad Thing. But since we're not (yet ?) considering DML abstraction, I'm not sure we can go much further... except (maybe) by some very clever hook_db_rewrite_sql implementations. (very ?). Frederic. ----- Original Message ----- From: "Barry Jaspan" <barry@jaspan.org> To: <development@drupal.org> Sent: Friday, January 26, 2007 8:03 PM Subject: Re: [development] Database schema abstraction and *reflection*(was: Referential integrity -- finally?)
"FGM" <fgm@osinet.fr> writes:
[...]
What I see in your diagram is that you took the realm column out of node_access into its own table, keyed by a realm id. It looks to me like this is just normalizing the node_access table. Am I correct? [...]
I'm not sure I understand your question, but I think you are asking: Could this abstraction allow the Drupal-Firebird driver to convert the current node_access table into the separate node_access and node_access_realm tables as shown in your diagram?
If that is the question, the answer is no. My proposal is only for data-definition statements, not for abstracting data-manipulation statements. Yes, one could implement the hypothetical hook_schema_alter (I'm making this up on the fly):
function firebird_schema_alter(&$schema) { unset($schema['node_access']['cols']['realm']); $schema['node_access']['cols'][] = array('rid', ...); $schema['node_access_realm'] = array(/* table definition goes here */); [...]