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! db_create_table('client_system', array( '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/