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

[Frando]

Bèr Kessels schrieb:
> Op zaterdag 13 mei 2006 14:50, schreef Dries Buytaert:
>   
>> 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.
>>     
>
> There is a way inbetween this too. The Middle Road. And that is how Active 
> Record works. 
> Let us forget about OO vs non OO for a second and look at this:
>
> Comment.find_by_id(12)
> Comment.title = "Foo Bar"
> Comment.save!
>
> But you can also do:
> Comment.find(:first,
> 		     :conditions => "id = 12")
> ..same as above ..
>
> And even:
> Comment.find_by_sql("select * from comments where id = 12")
> ..same as above..
>
> Now. The point is that in your Day to Day work, you need not bother about SQL.  
> But that is not the same as "not being allowed to use SQL". 
>
> David Heinemeier Hansson:
> "Some object-relational mappers seek to eradicate the use of SQL entirely..."
> "..Active record does not. It was built on the notion that SQL is neither 
> dirty nor bad, just verbose in the trivial cases."
> "... Therefore, you shouldn't feel guilgy when you use find_by_sql() to handle 
> either performance bottlenecks or hard queries. Start out using the 
> object-oriented interface for productivity and pleasure, and then dip beneath 
> the surface for a close-to-the-metal experience when you need to".
>
> Which IMO is how we should treat Drupals "abstraction layer" too. 
>
> Not try to pull out the SQL etc for sake of abstraction. Not making stuff more 
> OO for the sake of portability. But only to make working on Drupal more fun, 
> faster, and more productive. 
>
> We should really try to avoid becoming a platform that you "fight against to 
> get stuff done your way". It should be a fun and productive thing to do, 
> working on a Drupal site. Working with Drupal should leave you all warm and 
> fuzzy. With a "wow! this is very smart and usefull" erlebnis every hour.
>
> Instead of a "why the *** cant I just use foo bar here. Wy the *** do i need 
> to read sqlApiLayers introductions and manuals when all I need is to store a 
> value."
>
> I am not saying this is the case now. But I fear that if we continue rolling 
> down the road of more complexity and more abstraction, without remaining 
> pragmatic, we are going to loose precious developers.
>
> Bèr 
>
>   

+1.
I think, ActiveRecords in drupal would just be perfect. For my last 
project, I used a php framework called CakePHP [1]. It's quite similar 
to RoR, but written in php. It implents a lot of ActiveRecords stuff, 
and I never created a web app faster.

Especially for simple, every-day-work, for example by coding quite a 
simple data managment module, ActiveRecords saves not only a lot of 
code, but also a lot of time.

I can't see any reasons against including ActiveRecords in drupal, 
espacially because no one will be forced to use them, but a lot of 
people will.

best regards,
frando

[1] www.cakephp.org