Hm. I was also thinking.... If we have RI...we should start to think about transactions implementation of some sort, thus you don't have a parent table w/o any child tables (node table entry w/o a node_revisions table entry). Although, this should be handled at the application level (what I like to call pessimistic coding: e.g. in hook_insert a simple if(!db_query($my_sql_statement)) { node_delete($node->nid); // set error msg }. Thus we get do not get any 'phantom' parent tables. I think this is something that should be added to the developer hand book perhaps. A section on error handling. Most modules follow an 'optimistic' coding practice where most things are assumed that they work with no errors. Sorry, getting off topic. Also with regards to RI..it shouldn't be to bad. The main parent table in Drupal is the node table. After that, most everything references the nid generated from the node. If we do go RI however, I think that doing away with auto_increment would make things easier. Gerhard Killesreiter wrote:
Sammy Spets wrote:
Good point Adrian,
I think there needs to be some effort put in to better the abstraction we currently have. e.g db_add_column() only exists for PostgreSQL. We'd get rid of a mountain of code if all updates were moved to use that function for both MySQL and PostgreSQL. It would also reduce the barrier for module developers to write PostgreSQL compatible code.
What do you guys think of this?
Problem is that Dries doesn't like this _at_ _all_. :p
His argument is IIRC that we should stick to as plain SQL as possible to not further increase the barrier of entry for people already knowing SQL.
While his argument has merit, I think it is put ad absurdum by the fact, that Drupal doesn't have any plain sql files anymore.
Cheers, Gerhard