"FGM" <fgm@osinet.fr> writes:
When doing a Firebird 1.x port of Drupal, I met a limitation of the underlying DBMS with the node_access table, which can't be created with a structure equivalent to the MySQL/PGSQL versions (see http://cvs.drupal.org/viewcvs/drupal/contributions/docs/developer/database/c... for the workaround).
I do not claim to be wise in all the ways of databases, nor have I ever touched Firebird, and I am only somewhat familiar with the node_access table. 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?
Would that level of abstraction enable us to use this type of solution (an additional table f-keyed to a base table) ?
I certainly plan to support foreign-key information in the schema data structure even if it is not represented/enforced by the underlying DBMS. This is crucial to achieving "Drupal understanding its own schema." 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 */); } However, that would break all the code that calls the CRUD functions on node_access. I do NOT want to put an abstraction layer on top of SELECT. For this change, the schema would just need to be changed and code using node_access would have to be patched. Am I misunderstanding your question? Thanks, Barry