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

[James Gilliland]

I'm going to do some Bèr's praise here.  I'm usually really strict
about the DNRY personally.  Though I use 3 instances as a clue that
I'm going to need to split the code into a function.

Continuing that train of thought, how many time have you had to do
some sort of INSERT/UPDATE switch in you drupal code?  I think Bèr is
right on in suggesting we consider something like AR.  It's a little
more OO than drupal has been in the past do to overhead concerns but
I'm not sure that applies here.

Big +1 from me.

James

On 5/12/06, Bèr Kessels <ber at webschuur.com> wrote:
> Op vrijdag 12 mei 2006 18:00, schreef Dries Buytaert:
> > I, for one, find it much easier to read an SQL statement than some
> > (new) Drupal-specific table definition. I don't want to learn or use
> > a such definition language. Such functions make the database scheme
> > less transparent.
>
> The agility! wonderfull ;)
>
> 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.
>
> If we go for some DB abstraction layer, we should really, IMnsHO look at
> Active Record (PHP stuff at
> http://phplens.com/phpeverywhere/?q=node/view/228), wich does not take SQL
> away from developers but makes it easier to use. A Big Difference, IMO.
>
> Whether we go for AR itself or some AR library, the central point should IMO
> be: "make it easier for developers to build sites".
>
> Wich is far from "make a system in such a way that developers are pushed to
> build technical better system". Drupal, IMO is walking slowly towards the
> latter the way its going now. A pity, because it does not make things better.
> Only "technical better".
>
> Bèr
>