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

[James Gilliland]

I want to jump back a bit and make a quick point.  Coming in just recently
and doing a *lot* of converting old fapi to new, the new api is a lot easier
to understand and work with for me.  For one thing I don't have to worry
about the the args for each func or even one func.  The keys are descriptive
and tell you what your adding and are common among most form elements.  All
it required was a basic understanding of html form which should be a
requirement anyways  My point is fresh eyes see things different.

Also, I have several installs with no coding what so ever.  Every time I'd
come to merlin with "I think I'm going to code a module to do X", he'd tell
me to look at module Y he or someone else had already written.

That aside and back on topic.   I know drupal is a scratch your own itch
sort of system but its growing fast.  I think a lot of people here have been
hinting at this but pretty soon the firebird guys are going to be wanting to
post compatibility patches to core.  And then(pull out those buzzword bingo
cards and get ready) someone's boss is going to ask if they can run an
"enterprise" ready install of drupal on oracle. Suddently our update
functions are 200lines long instead of 50 and our .install files are 10k.
I'm probably exagerating a little but those seem like some serious
maintainability issues.

Also, I have a good grasp of SQL, both mySQL and plSQL(not really pgSQ:
yet), but

>
> Comment.find_by_id(12)
> Comment.title = "Foo Bar"
> Comment.save!


is actually easier to read for me.  Maybe that's just a design practice
modules should use more but I think there's room to take some of the SQL leg
work of the drupal dev.


James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060513/b399b53f/attachment.htm