[development] Extend database abstraction layer, to include table creation.

[Gerhard Killesreiter]

Dries Buytaert wrote:
>
> On 13 May 2006, at 00:17, Bèr Kessels wrote:
>> Serious: What Drupal needs above all, is not some "Higher Language To 
>> Talk To
>> Lower Languages", but a way to make stuff easier.
>>
>> IMveryHO forms api surpassed its goal in this: What is easier: calling
>> form_weight() or building an object-from-drupal-specific-arrays? 
>> Point is
>> clear.
>
> I agree.  While Drupal becomes more powerful, it also becomes more 
> difficult to develop for.
>
> Drupal 4.7's new forms API is a prime example.  It is obviously great 
> in terms of security and flexibility, but at the same time, it is also 
> _much_ harder to use than the old form API.  What does that mean?  
> Well, that some people can make really fancy forms but that the 
> majority of the people will find it more difficult to make basic forms.

I disagree. It isn't that much harder to use. The separation of 
validation and submit action into separate functions makes the code much 
more readable and easier to see what is going.

I am currently upgrading my evaluation module, which has huge forms,  
and really appreciate this.

> This is somewhat problematic as we need more people that are good 
> Drupal developers.  There is such a

We recently got some very nice additions to our developer crowd.

> strong demand for good Drupal developers, yet which each new version, 
> we add more barriers as a side effect of making Drupal more powerful.

I think this is only a matter of perception. You (as I was) aren't yet 
fully comfy with the new forms API and thus think that everybody will 
find it more difficult. For people who are new to it, they will just 
read the (excellent!) docs and should be able to make the usual forms 
within a few minutes.

>   As a result, we'll get many more users, but relatively fewer 
> developers.  And that's a big problem.
>

We will always get less new developers than new users.

> For most of us eliminating the various SQL schemas makes perfect 
> sense.  After all, most of us are expert Drupal developers, and as 
> such, an incremental improvement is easy enough to deal with.  
> However, for new Drupal developers, who are not intimate with Drupal's 
> code, this just increases the barrier.

Here's a point where I agree. I wouldn't want to add a load of new db 
functions like the proposed db_fetch_all_*. This just confuses matters 
and people don't know which to use when. However, I'd be in favour of 
functions such as db_add_column or db_create_table. I also would like to 
bring this old much of mine to everybody's attention again 
(http://drupal.org/node/17656). Any new database abstraction that we add 
should be able to address the subject of this patch.

> Why did you end up with Drupal to begin with?  Because it had an 
> extremely powerful API for every single problem?  Or because it was 
> clean code, easy to get into and make work?

Because it had web based translation and was rather conservative in its 
demands wrt software versions. :p
Also, I thought I would eventually be able what PHP is.

> The web is built by millions of individuals, many of which are 
> amateurs. They continuously update, tweak and rebuild their websites.  
> We want Drupal to remain accessible for them.

Do we? I certainly want them to be able to use Drupal but I'd appreciate 
if they'd keep their hands out of the code if they aren't programmers. 
This only makes for nasty support cases.

> Hence, the challenge is to make Drupal more powerful _AND_ easier to 
> develop for.  This requires that we question certain development 
> directions and look at them through the eyes of amateurs.
>

Call it "budding PHP programmers" and I am with you, but we shouldn't 
use Drupal as a teaching toy for amateurs.

Cheers,
    Gerhard