[development] Referential integrity -- finally?

Frando (Franz Heinzmann) frando at xcite-online.de
Wed Jan 24 19:40:08 UTC 2007

This whole issue was already discussed somewhere near the end of the 
last cycle, and back then I wrote an implentation of this whole thing.

It was the result of the discussion back then, and is actually very 
similar to what you are proposing.

The patch is here:

It provides a very basic API for creating tables, adding and removing 
columns, and adding and removing indexes. Type declarations are based on 
the concept of some default data types that provide default parameterers 
that can all be overridden easily (comparable to fapi).

So far, it's only done in/for MySQL (as I'm not at all familiar with 
Postgres), however, it shouldn't be too hard to port it to other engines 
for people who are familiar with them.

It will probably not apply cleanly anymore, and there is probably space 
for improvements, however, the concept should become clear, and a reroll 
will be easy.


Earnest Berry III schrieb:
> I'm planning on handling the MS-SQL port; I agree, the create DML 
> functions should be created.....but SQL should be left to the user. I 
> know we're always trying to get new/more developers. But, if the 
> information that a "newbie" needs from the database requires a complex 
> query, the either:
> A) Need to be adapt enough at programming to use simple SQL statements 
> and application logic to produce the
> desired results (this will then prob. be refactored by the community 
> after having a look at it, and some nice person
> will write the complex query for them)
> B) Contact someone for help
> C) If they are not adapt at programming, then they can't really create a 
> module in the first place, and that is a whole
> other issue.
> So yes, we want more people and s short learning curent, which I believe 
> is there. I think this talk is for people who want to better maintain 
> their modules (DB wise), support more DB's, and still offer the fine SQL 
> control for optimization for advanced queries/statements/etc.
> We should prob. start to come up with some standards for naming during 
> creations, etc.
> Example, if I do a db_create_table(array('col1' => array('type' => 
> 'number'), 'options' => array('index' => array('col1')))));
> // Creates a table with a column col1 with an index
> The index should be called 'idx_col1' (naming convention index = idx). 
> so that when other DML statements happen, we're accessing the same 
> index/PK/FK names across DB's.
> So, I'll start:
> indexs = idx_[col_name1]_[col_name2]_[...]
> Primary Key = PK
> FK = FK_[parent_col]_[child_col]_[..]
> Good idea/bad idea?
> adrian rossouw wrote:
>> On 24 Jan 2007, at 5:20 PM, Dries Buytaert wrote:
>>> The 'database scheme definition' vs 'standard query language' (or 
>>> 'data manipulation language') argument make sense to me -- although 
>>> it would be great if you had pointers to references.
>>> Either way, I'm willing to reverse my position on creating database 
>>> abstraction functions for create or altering SQL tables -- but not to 
>>> build SELECT/UPDATE/INSERT queries.
>> Great news.
>> Perhaps we should contact the people handling the different DBMS ports. ?
>> Also, this might make sqllite more easily implemented. I believe it 
>> doesn't even have an alter mechanism, and
>> you need to use application code to recreate tables and the like. 
>> http://code.jenseng.com/db/

Frando? Gaunab?
-Unbiskant: http://unbiskant.org

More information about the development mailing list