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&nbsp; My point is fresh eyes see things different.<br><br>Also, I have several installs with no coding what so ever.&nbsp; Every time I'd come to merlin with &quot;I think I'm going to code a module to do X&quot;, he'd tell me to look at module Y he or someone else had already written.
<br><br>That aside and back on topic.&nbsp;&nbsp; I know drupal is a scratch your own
itch sort of system but its growing fast.&nbsp; 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.&nbsp; And then(pull out those buzzword bingo cards and get ready) someone's boss is going to ask if they can run an &quot;enterprise&quot; ready
install of drupal on oracle.
Suddently our update functions are 200lines long instead of 50 and our
.install files are 10k.&nbsp; I'm probably exagerating a little but those
seem like some serious maintainability issues.<br><br>Also, I have a good grasp of SQL, both mySQL and plSQL(not really pgSQ: yet), but <br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<br>Comment.find_by_id(12)<br>Comment.title = &quot;Foo Bar&quot;<br>Comment.save!</blockquote><div><br>is actually easier to read for me.&nbsp; 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.
<br></div><br><br>James<br>