Data-driven database tables and updates
Nothing like sticking your neck out, eh? :-) One of the major improvements in 4.7 is the data-driven Forms API. Instead of having modules generate/munge form HTML directly, they generate and return a data structure describing the form they want. This leads to all kinds of benefits I don't need to enumerate here. Another major improvement in 4.7 is hook_install() and hook_update_N() which allow modules to programatically create and modify their own tables. Good stuff, but the modules must maintain separate code for MySQL and Postgres and generate/munge their tables directly. IMHO, _install() and _update_N() are to 4.7 what the pre-Forms API form-building techniques were to <=4.6. So, why not create a data-driven table creation/modification API? I'm not proposing a complex abstraction over all possible data storage mechanisms, just something that is enough to generate "CREATE TABLE" statements for MySQL and Postgres and, more importantly, allows Drupal to reflect on its own database scheme. Now that I think about it, I bet CCK has something like internally already. I haven't looked inside CCK yet. Very roughly, I'm envisioning something like this: function modulename_schema() { $tables['event']['#charset'] = 'utf8'; $tables['event']['nid'] = array( '#type' => DB_INT, '#dispwidth' => 10, '#signed' => FALSE, '#null' => FALSE, '#default' => '0'); $tables['event']['event_start'] = array(...); ...; return $tables; } This will provide numerous other advantages, most of which I probably haven't thought of. One would be to more cleanly control scheme changes for updates. One option would be to include a '#schema' version number field. For simple new columns, the Database API could execute the ALTER TABLE itself. For more complex changes, the module could specify a callback. Obviously the idea would need to be fleshed out more. If there is interest and is not already being done, I'll take it on (or at least get it started). Comments? Barry
On 6/9/06, Barry Jaspan <barry@jaspan.org> wrote:
Obviously the idea would need to be fleshed out more. If there is interest and is not already being done, I'll take it on (or at least get it started).
Comments?
You've seen this discussion, right? http://lists.drupal.org/archives/development/2006-05/msg00456.html The 118 messages on basically the same subject from ~2 weeks ago. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
function modulename_schema() {
$tables['event']['#charset'] = 'utf8';
$tables['event']['nid'] = array( '#type' => DB_INT, '#dispwidth' => 10, '#signed' => FALSE, '#null' => FALSE, '#default' => '0');
$tables['event']['event_start'] = array(...);
...;
return $tables; }
Adrian Roussow is working on something like this already. This will make the schema more portable across PostgreSQL and MySQL and other databases. Check the previous discussion here http://lists.drupal.org/pipermail/development/2006-May/015962.html
On 09 Jun 2006, at 3:30 PM, Khalid B wrote:
Adrian Roussow is working on something like this already.
I wish I was. But sadly Dries has (in no uncertain terms) said he didn't like the idea. The only other compromise we found was to use an SQL parser, that automatically translates from one DDL to another. I couldn't track down the exact one chx mentioned though .. charlie ? -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 09 Jun 2006, at 19:44, Adrian Rossouw wrote:
Adrian Roussow is working on something like this already.
I wish I was. But sadly Dries has (in no uncertain terms) said he didn't like the idea.
If the majority of the people think this is a good idea, I'd be happy to go with this direction. As mentioned, I understand the advantages of said system, but I still prefer the transparency and simplicity of "raw" SQL statements. SQL is an abstraction layer, and one that is documented in hundreds of books and articles. It is my opinion that creating a Drupal- specific abstraction layer on top of an existing, standards compliant abstraction layer used by hundreds of thousands of people creates an additional barrier for developers that are new to Drupal, but that are familiar to SQL. I, for one, wouldn't want to learn an application specific SQL-like description language. As a developer, it would sorta turn me off, and make me shout 'bloat!'. -- Dries Buytaert :: http://www.buytaert.net/
On 6/10/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
SQL is an abstraction layer, and one that is documented in hundreds of books and articles. It is my opinion that creating a Drupal- specific abstraction layer on top of an existing, standards compliant abstraction layer used by hundreds of thousands of people creates an additional barrier for developers that are new to Drupal, but that are familiar to SQL.
The same could be said of forms. HTML forms are also a well-documented abstraction layer, for getting data from users of a web app, in a standard way. Yet we have a Drupal-specific abstraction layer on top of them (i.e. the Forms API). Cheers, Jaza.
Op 10-jun-06, om 04:19 heeft Jeremy Epstein het volgende geschreven:
On 6/10/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
SQL is an abstraction layer, and one that is documented in hundreds of books and articles. It is my opinion that creating a Drupal- specific abstraction layer on top of an existing, standards compliant abstraction layer used by hundreds of thousands of people creates an additional barrier for developers that are new to Drupal, but that are familiar to SQL.
The same could be said of forms. HTML forms are also a well-documented abstraction layer, for getting data from users of a web app, in a standard way. Yet we have a Drupal-specific abstraction layer on top of them (i.e. the Forms API).
The situation with HTML forms is quite different... HTML form tags work on the level of UI widgets. <input type="checkbox" /> only describes the checkbox itself. You need to add the label around it with extra markup. The same goes for textfields: <input type="textfield" /> is the UI widget itself. The label, the description and most importantly: the <div class="form- item"> that conceptually groups what one would think of as "the form item" is all extra markup. This is why we need form API: to have an abstraction layer that works on the level of form items, and not just individual widgets. It even goes beyond: thanks to attributes, we can add behaviours such as autocomplete and collapsable sections easily. They all involve significant extra work in the HTML, which is abstracted away. Wrapping another layer around SQL on the other hand, is useless unless you actually abstract other things as well. Steven Wittens
On Jun 9, 2006, at 3:31 PM, Dries Buytaert wrote:
On 09 Jun 2006, at 19:44, Adrian Rossouw wrote:
Adrian Roussow is working on something like this already.
I wish I was. But sadly Dries has (in no uncertain terms) said he didn't like the idea.
If the majority of the people think this is a good idea, I'd be happy to go with this direction.
As mentioned, I understand the advantages of said system, but I still prefer the transparency and simplicity of "raw" SQL statements.
SQL is an abstraction layer, and one that is documented in hundreds of books and articles. It is my opinion that creating a Drupal- specific abstraction layer on top of an existing, standards compliant abstraction layer used by hundreds of thousands of people creates an additional barrier for developers that are new to Drupal, but that are familiar to SQL.
I, for one, wouldn't want to learn an application specific SQL-like description language. As a developer, it would sorta turn me off, and make me shout 'bloat!'.
The data management battle has boiled down down to three basic implementations over the last 40 years: relational (System R, Oracle, MySQL), hierarchical (LDAP and IMS), and network,now abstracted as object or XML databases which is closest to the proposed new system at first glance. Each has had its moment. Relational wins every time, not because of a standard, performance, or because developers like to use it. It wins because it has superior reporting capabilities that allow for the boss to ask questions and get answers fast. Bosses who get the right information faster tend to stay in business longer. If we choose to stay with a relational and SQL based query model then we need to ensure that our priority is on reporting. What this means for core is that we must compete against the alternate solutions in several ways to have a better overall package. 1) A better interface for statistics to provide advanced reporting analysis. 2) Integration of Views into core to allow administrator capable reporting to the UI. E.g. Calendar views. 3) A focus on supporting built in analysis like the SOC project Social Network Analysis Tool, and other data analysis techniques like data mining and data ware housing. If we choose to take the ROR Network/Object/XML DB path then we will have a lot of very happy developers who will buy lots of books, sell out conferences for a while and then realize we can't give the executive's the answers fast enough before they layoff the techies. Alternately, we can choose the Hierarchical DB Model and build one really big hierarchical database like Google's Big Table project to store the worlds content. This will ensure Google stays speedy for all of us. It has it's place in a world where search competes for public attention. However, reporting still rules the world and I think that's where we should stay focused. Kieran
-- Dries Buytaert :: http://www.buytaert.net/
On 6/9/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 09 Jun 2006, at 19:44, Adrian Rossouw wrote:
Adrian Roussow is working on something like this already.
I wish I was. But sadly Dries has (in no uncertain terms) said he didn't like the idea.
If the majority of the people think this is a good idea, I'd be happy to go with this direction.
As mentioned, I understand the advantages of said system, but I still prefer the transparency and simplicity of "raw" SQL statements.
SQL is an abstraction layer, and one that is documented in hundreds of books and articles. It is my opinion that creating a Drupal- specific abstraction layer on top of an existing, standards compliant abstraction layer used by hundreds of thousands of people creates an additional barrier for developers that are new to Drupal, but that are familiar to SQL.
I, for one, wouldn't want to learn an application specific SQL-like description language. As a developer, it would sorta turn me off, and make me shout 'bloat!'.
What about a simple helper script that sucked in .mysql files and generated it for you? You could then learn the app specific stuff if you wanted to do some of the special tricks or abilities that this enables. I agree that adding yet-another-special-Drupal thing adds complexity for new developers. But part of what makes Drupal interesting/powerful is some of our helper functions and abstraction layers. Reading Ken Rickard's description of how Drupal helped him learn good PHP is very interesting: http://ken.therickards.com/2006/06/04/tech-notes/ Clearly, this is one of those areas where some small group of folks will have to join forces and give this a shot to see if it makes sense, and then we can poke holes in running code. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On 10 Jun 2006, at 8:02 AM, Boris Mann wrote:
Clearly, this is one of those areas where some small group of folks will have to join forces and give this a shot to see if it makes sense, and then we can poke holes in running code.
http://drupal.org/node/63049 There's already a patch. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Dries Buytaert wrote:
It is my opinion that creating a Drupal-specific abstraction layer on top of an existing, standards compliant abstraction layer Standards compliant? Ah right, so we don't actually need a drupal specific abstraction layer, because MySQL and pgSQL both understand SQL, and thus we only need one piece of SQL code to create or update each db or table, and in fact Oracle or any other SQL db out there...
But back here in the real world each db has it's own modifications and idiosyncrasies, SQL may be a standard, but the databases that use it aren't standards compliant. Or have I misunderstood?
I, for one, wouldn't want to learn an application specific SQL-like description language I think you've overblown that just a little. Adrian has specifically said he wants to make a few operations easier when updating and installing drupal and it's modules, not create an entire SQL-like language. And he wants to do it so developers can support more than one db without having to learn 2 or 5 different variants of SQL.
More to the point - if I'm remembering the previous version of this thread properly - a small abstraction system wouldn't even stop people using SQL directly if they prefered. -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On 6/10/06, Adrian Simmons <adrinux@perlucida.com> wrote:
Dries Buytaert wrote:
It is my opinion that creating a Drupal-specific abstraction layer on top of an existing, standards compliant abstraction layer Standards compliant? Ah right, so we don't actually need a drupal specific abstraction layer, because MySQL and pgSQL both understand SQL, and thus we only need one piece of SQL code to create or update each db or table, and in fact Oracle or any other SQL db out there...
But back here in the real world each db has it's own modifications and idiosyncrasies, SQL may be a standard, but the databases that use it aren't standards compliant. Or have I misunderstood?
That was my objection in the email thread on abstraction. Abstracting table creation is nice, and has value. What I am against is that there is no real 100% abstraction beyond table creation. At best it will be lowest common denominator, and performance cannot be achieved without tweaking to the specific database.
What I am against is that there is no real 100% abstraction beyond table creation. At best it will be lowest common denominator, and performance cannot be achieved without tweaking to the specific database.
please, we are only talking about schema definitions. performance is a non issue.
On 10 Jun 2006, at 4:03 PM, Moshe Weitzman wrote:
creation. At best it will be lowest common denominator, and performance cannot be achieved without tweaking to the specific database.
please, we are only talking about schema definitions. performance is a non issue. Not necessarily.
Different databases could still have different optimal index configurations. This code is meant to cover the 95% of cases, however. And there's nothing stopping us from still using if ($db_type['mysql']) { // some mysql specific alterations / optimisations } It's not a way to stop people from having to learn sql. SQL is still a pre-requisite for developing with Drupal. It is only meant to save the developer from having to know 2 or 5 different variants of sql just to fully support our feature set. It is still almost exactly like sql, it's just broken up into a more readily accessible data structure for us to work with it. When it comes down to it, the code is in all practicality like theme () functions for sql statements. Switching to different output based on db_type, not different selected theme. I am also ok with using the sql parser found here (http://cvs.sf.net/ viewcvs.py/easymod/sql_parser/root/includes/sql/) since the end result is the same. Whether Dries wants to admit it or not, the current inequality of postgres and mysql support is a maintenance nightmare. Now that automated installs are happening, the demands of keeping the code in synch are only going to grow, and the problems from failing to do so, will become more apparent. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
This discussion about the virtues/evils of database application layers is weird. I don't know if I'm missing something. When it comes down to it, this is *not* SQL: db_query('SELECT COUNT(vid) FROM {ec_product} WHERE vid = %d', $node->vid) So any (potential) Drupal programmers who can't handle a database application layer have already left the building. Bye bye programmers, sorry you couldn't work out the whole %d %d %s %s %s thing!
creation. At best it will be lowest common denominator, and performance cannot be achieved without tweaking to the specific database.
please, we are only talking about schema definitions. performance is a non issue.
I am not against the proposed schema creation abstraction. It is a good idea. Dries can take another look at it and see its merits (takes away the pain of having two create table statements). Like Adrian said, we are not enforcing this to be The Only Way. db_query() is still there, and anyone can put create tables in that. My objection was what this *may* lead to in the mind of some "let's abstract everything", then we are in trouble.
On 10 Jun 2006, at 7:19 PM, Khalid B wrote:
My objection was what this *may* lead to in the mind of some "let's abstract everything", then we are in trouble.
Oh . i believe there is a definite line there. It's perfectly possible to write select , update and insert statements that work in both postgres and mysql. It is perfectly impossible to do the same with DDL. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Sat, 10 Jun 2006 19:33:59 +0200, Adrian Rossouw <adrian@bryght.com> wrote:
On 10 Jun 2006, at 7:19 PM, Khalid B wrote:
My objection was what this *may* lead to in the mind of some "let's abstract everything", then we are in trouble.
Oh . i believe there is a definite line there.
It's perfectly possible to write select , update and insert statements that work in both postgres and mysql. It is perfectly impossible to do the same with DDL.
Well, markus has a nice library for phpBB that uses something very close to mysql DDL AND is cross DB.
On 10 Jun 2006, at 8:38 PM, Karoly Negyesi wrote:
Well, markus has a nice library for phpBB that uses something very close to mysql DDL AND is cross DB.
Yup. and I fully support a patch that uses it. The only reason I recommended we do db_* functions, is because it has fewer moving parts, and is pretty much like what we already have. I didn't want to see us write an sql parser, but if one already exists (which coincidentally happens to be written by a trusted drupal contributor) we should definitely use it. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
On 10 Jun 2006, at 8:38 PM, Karoly Negyesi wrote:
Well, markus has a nice library for phpBB that uses something very close to mysql DDL AND is cross DB.
Yup. and I fully support a patch that uses it.
The only reason I recommended we do db_* functions, is because it has fewer moving parts, and is pretty much like what we already have.
I didn't want to see us write an sql parser, but if one already exists (which coincidentally happens to be written by a trusted drupal contributor) we should definitely use it.
Just for the record: I don't really like parsers. I'd prefer we write our SQL as structured arrays. It will still be readable as SQL and it is easier to manipulate, ie insert additional conditions or remove them. Cheers, Gerhard
On 10 Jun 2006, at 9:25 PM, Gerhard Killesreiter wrote:
Just for the record: I don't really like parsers.
I'd prefer we write our SQL as structured arrays. It will still be readable as SQL and it is easier to manipulate, ie insert additional conditions or remove them.
Yup. Like i said. structured arrays have fewer moving parts, and I'm also not fond of parsers =) Although i'm worried about the idea of having conditionals inside the sql =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
On 10 Jun 2006, at 9:25 PM, Gerhard Killesreiter wrote:
Just for the record: I don't really like parsers.
I'd prefer we write our SQL as structured arrays. It will still be readable as SQL and it is easier to manipulate, ie insert additional conditions or remove them.
Yup. Like i said. structured arrays have fewer moving parts,
Right.
and I'm also not fond of parsers =)
Yay!
Although i'm worried about the idea of having conditionals inside the sql =)
Well, we sort of already have this courtesy of db_rewrite_sql. Cheers, Gerhard
On Saturday 10 June 2006 14:25, Gerhard Killesreiter wrote:
I didn't want to see us write an sql parser, but if one already exists (which coincidentally happens to be written by a trusted drupal contributor) we should definitely use it.
Just for the record: I don't really like parsers.
I'd prefer we write our SQL as structured arrays. It will still be readable as SQL and it is easier to manipulate, ie insert additional conditions or remove them.
Cheers, Gerhard
Would this be the appropriate time to say that I've a patch awaiting feedback that does exactly that for INSERT, UPDATE, and DELETE statements? :-) http://drupal.org/node/53488 (Originally written because I despise SQL's INSERT syntax, but I've found them very convenient for flexibility, too.) Doing the same for SELECT statements is harder, because SELECT statements are potentially an order of magnitude more complex. It has been done, though, (PEAR::DB_DataObjects comes to mind), if we really want to go that route. That's a separate issue, though. As for database/table/schema creation, yes please! As a module developer, I work in MySQL because that's what my hosts have and what I know. At the same time, I don't want to make my module non-Postgres friendly simply through ignorance but really don't have the time to learn Postgres' ins and outs. A simple way to support all Drupal-supported databases for table creation means more modules that support Postgres out of the box. (They could still have MySQLisms in the code itself, but that's less likely and a separate issue.) More to the point, it means that if the Oracle or MSSQL or SQLite support patches ever hit core, they'll have a grand total of 0 contrib modules that support them right now. If most of contrib were using some thin table creation abstraction layer, then Oracle or whatnot would have support of most of core out of the box. That's a good thing. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Would this be the appropriate time to say that I've a patch awaiting feedback that does exactly that for INSERT, UPDATE, and DELETE statements? :-)
Indeed, I like the db_insert/friends approach, and I like the the arrays as well. They actually complement each other well. Probably I should add I like parsers, where they make sense. Here they won't.
Doing the same for SELECT statements is harder, because SELECT statements are potentially an order of magnitude more complex. It has been done, though, (PEAR::DB_DataObjects comes to mind), if we really want to go that route. That's a separate issue, though. views and cck pave the way to inserts. And we have some experience with similarly complex issues due to forms api.
Abstracting certain interactions with SQL is necessary. We do it already (the pager system, anyone?) when it makes sense. Other parties are expressing interest in both MSSQL and Oracle implementations for Drupal, and adding those databases into the mix only makes the problem of schema definition more apparent. Writing 'generic' SQL for queries is relatively easy if you're careful. Writing 'generic' SQL for schema definition is impossible. Thus, schema definition makes sense as a point of abstraction. Treating it as a general SQL task ignores the myriad compatability issues between various DB systems. That's my $0.02. :) --Jeff
Just to play devil's advocate here: Many programmers who "know" SQL really don't know it very well. The number of really good database developers working on Drupal is smaller than the number of good PHP developers. While I'm against bloat and yet another API to learn, one argument in favor of a Drupal database API is so that the database is architected by developers who really understand efficient relational database construction and usage, and the SQL for accessing it is likewise good -- instead of a more random quality we have now.
Chris Johnson wrote:
Just to play devil's advocate here:
Many programmers who "know" SQL really don't know it very well.
This is certainly true for myself and most of the other core developers. :p
The number of really good database developers working on Drupal is smaller than the number of good PHP developers. While I'm against bloat and yet another API to learn, one argument in favor of a Drupal database API is so that the database is architected by developers who really understand efficient relational database construction and usage, and the SQL for accessing it is likewise good -- instead of a more random quality we have now.
Makes sense to me. Cheers, Gerhard
Chris Johnson wrote:
Just to play devil's advocate here:
Many programmers who "know" SQL really don't know it very well.
This is certainly true for myself and most of the other core developers. :p
The number of really good database developers working on Drupal is smaller than the number of good PHP developers. While I'm against bloat and yet another API to learn, one argument in favor of a Drupal database API is so that the database is architected by developers who really understand efficient relational database construction and usage, and the SQL for accessing it is likewise good -- instead of a more random quality we have now.
My turn for devil's advocate: What you say is true. However, programmers and database modelers/architects are two different skills. In large environments, the architect normalizes the database first to 3NF, the denormalizes and adds indexes to enhance performance for most common access paths. Of course, this is what happens in large waterfall development shop, and not in iterative development like most Open Source is. Let us assume that is not an issue with Drupal, and that the core developers are also efficient database architects (which is mostly true). This leaves out contrib, which is very variable, and no database optimization happens for the vast majority of modules. I am not sure if anything can be done here to improve this though. There is no silvert bullet for this one.
On 6/11/06, Khalid B <kb@2bits.com> wrote:
I am not sure if anything can be done here to improve this though. There is no silvert bullet for this one.
I agree very much with Khalid on these points. I was quite surprised that subscription module uses serialize/unserialize of arrays and does it's matching in PHP instead of in the db. The db is tens of times (hundreds, thousands?) faster at doing matching than a PHP loop. Probably the best thing to do is get more database savvy folks interested in helping out with Drupal. I'm not sure what the best way is to do that. Advertise to MySQL User Groups? My proposed solution of getting more db developer's involved probably points more towards keeping as much in standard SQL as possible so that they recognize it when they see it. Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
On 6/12/06, Greg Knaddison - GVS <Greg@growingventuresolutions.com> wrote:
On 6/11/06, Khalid B <kb@2bits.com> wrote:
I am not sure if anything can be done here to improve this though. There is no silvert bullet for this one.
I agree very much with Khalid on these points. I was quite surprised that subscription module uses serialize/unserialize of arrays and does it's matching in PHP instead of in the db. The db is tens of times (hundreds, thousands?) faster at doing matching than a PHP loop.
Another example of why abstraction can be a bad thing. It devolves into lowest common denominator or forces us into portable solutions that are not flexible (e.g. use of unix time stamp is portable, but deprive us of doing intervals in the backend. The dilemma here is: Drupal is used for personal blog where this stuff should not matter at all, but it is also used for large heavy traffic sites where this stuff matters.
As mentioned, I understand the advantages of said system, but I still prefer the transparency and simplicity of "raw" SQL statements.
SQL is an abstraction layer, and one that is documented in hundreds of books and articles. Well, all depends where do you want to draw the line. Raw sql allow you to define what do you want to do with the data. It becomes a burden if at some point you want to tinker with that precise logic. In drupal we are already doing something like that in a few places - db_rewrite_sql being the example in core. flexinode, cck, views do that as well. db_rewrite_sql is the most hairy example. I still refuse to read that particular function.
We do sql templates as well, via the db_query syntax, but that may not be enough. All of previous suggestions - arrays, function helpers, mini languages can be employed one way or another if there is really a big need for them - that is they really simplify the development by raising the abstraction and the flexibility of the code, help with code reuse, including db queries, and don't cause big performance degradation.
I, for one, wouldn't want to learn an application specific SQL-like description language. As a developer, it would sorta turn me off, and make me shout 'bloat!'. I wouldn't either :)
I hope you haven't all left the building yet ... it seems to me that there are two valid points here that are really looking at two different pieces. Specifically, as a module developer, I like my sql calls to be as direct as possible, not just because i don't want to learn something new, but mainly because I want it easier to debug (i'm syntaticly challenged...). Having to follow what's going on through a complex or opaque layer of abstraction is a huge waste of time (even assuming there's no bugs in it!). But I think that doesn't preclude an abstraction layer for automated scripts in core and contrib, where we can benefit from folks who have more sql expertise. I'm not a fan or cogenscenti of excessive abstraction, but I've been convinced by this thread of its benefits at the level of managing complexity and change ... So how does this split up? Well, it seems to me this is related to the whole discussion of the contribution modules and separating out the 'drupal-ready' stamped ones vs. the 'it worked on my site once upon a time' modules. So, part of the whole testing rigamarole that modules would have to go through in the process of getting some kind of stamp of approval would be to follow the required schemas of the abstraction layer that would allow for better automated scripts. $0.01 worth ... On 6/9/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 09 Jun 2006, at 19:44, Adrian Rossouw wrote:
Adrian Roussow is working on something like this already.
I wish I was. But sadly Dries has (in no uncertain terms) said he didn't like the idea.
If the majority of the people think this is a good idea, I'd be happy to go with this direction.
As mentioned, I understand the advantages of said system, but I still prefer the transparency and simplicity of "raw" SQL statements.
SQL is an abstraction layer, and one that is documented in hundreds of books and articles. It is my opinion that creating a Drupal- specific abstraction layer on top of an existing, standards compliant abstraction layer used by hundreds of thousands of people creates an additional barrier for developers that are new to Drupal, but that are familiar to SQL.
I, for one, wouldn't want to learn an application specific SQL-like description language. As a developer, it would sorta turn me off, and make me shout 'bloat!'.
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
participants (19)
-
Adrian Rossouw -
Adrian Simmons -
Alan Dixon -
Barry Jaspan -
Boris Mann -
Chris Johnson -
Dries Buytaert -
Gerhard Killesreiter -
Greg Knaddison - GVS -
Jeff Eaton -
Jeremy Epstein -
Karoly Negyesi -
Khalid B -
Kieran Lal -
Larry Garfield -
Moshe Weitzman -
sime -
Steven Wittens -
Vladimir Zlatanov