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: http://drupal.org/node/63049#comment-98967 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. regards, frando 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