[development] Extend database abstraction layer,
to include table creation.
dries.buytaert at gmail.com
Sat May 13 12:50:45 UTC 2006
On 13 May 2006, at 13:15, Derek Wright wrote:
> in general, i totally agree with the thrust of what dries is saying
> about trying to keep drupal easier to develop for. however, i also
> think adrian is right in this specific case that such a table
> creation and modification abstraction layer would be a good thing.
That is the thing. I agree with Adrian as well (I can see the
advantages), it's just that we need to be careful and look at this
from a beginner's point of view. We should avoid turning this thing
into a system that quacks like an enterprise-level CMS. In such
systems, you can define database schema's using XML, but at the end
of the day, they aren't used as much as Drupal. Guess why? Part of
the answer is that no one can install or customize such system
without hiring a consultant. That's not where we want to go.
> i'm not exactly an amateur, but i didn't know *any* SQL syntax as
> of 5 months ago when i first tried setting up a drupal site for my
> band. for me, the kind of abstraction layer adrian proposed (and
> others expanded on) would have probably helped me get up to speed
> more quickly. maybe i'm in the tiny minority of potential drupal
> developers who aren't already SQL wizards, but who know how to
> write code (i didn't know php either, but the syntax is enough like
> perl and C and the docs are good enough that i could figure it
> out). however, from my perspective as still something of a drupal
> novice, i don't think this would have slowed me down or deterred me
> in any way.
How can you understand the table definition proposed by Adrian (see
below), if you don't know any SQL? I don't think this gets you up to
speed any more quickly. Quite the contrary, you'd first have to
learn SQL and then you have to figure out how this Drupal specific
definition format maps onto it. Make no mistake, a Drupal-specific
definition language is no excuse for not having to learn MySQL. It
does add an additional step to the learning curve!
'cid' => array('type' => 'int', 'NOT NULL' => TRUE,
'PRIMARY KEY' => TRUE),
'name' => array('type' => 'short text', 'NOT NULL',
'default' => '', , 'PRIMARY KEY' => TRUE),
'type' => array('type' => 'short text', 'NOT NULL',
'default' => ''),
Hundreds of books have been written about PHP and MySQL. As a
newbie, you can buy these books and understand what Drupal's MySQL
schemas mean. If we add an extra abstraction layer, these books are
going to be less useful. Hence, we added a barrier.
It does, however, help you write portable code, but that isn't
something most people are concerned about. Newbies want to write
code that works, and that they can understand. Being able to
understand something is very rewarding/motivating. Portability is
not their main concern. IMO.
I'm not saying that the database definition function is a bad thing
or that we should drop it on the floor. We have to carefully
evaluate whether the advantages (portability) outweight the drawbacks
(less developers). All I can say, is that, as a programmer, I can
write SQL faster than I can write db_create_table() definitions.
Plus, I value the transparency of the "raw" SQL statements; at least
I know _exactly_ what is going on under the hood.
Here is something to think about (I'm still trying to figure out the
best way to formulate this):
The net effect of creating abstracting layers for everything is that
you're building a new programming language on top of the existing
languages (eg. PHP and MySQL). At some point, you'll loose some of
the underlying languages' advantages (eg. available documentation,
talent pool, transparency).
You see this happen in the Java world. Because of all the layers
(EJBs, Struts, JSTLs, JSPs, Beans, CMP, BMP, JAXM), J2EE started to
live a life on its own. Being a "regular" Java developer isn't
enough to get certain jobs.
Dries Buytaert :: http://www.buytaert.net/
More information about the development