[development] Referential integrity -- finally?

[Earnest Berry III]

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
>