[development] Database schema abstraction and *reflection* (was: Referential integrity -- finally?)

[Barry Jaspan]

"FGM" <fgm at 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/core.jpg?view=markup
> 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