On 7/28/06, <b class="gmail_sendername">Wilkes Joiner</b> <<a href="mailto:wilkesjoiner@gmail.com">wilkesjoiner@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I've been doing some Rails work lately. ActiveRecord is really nice,<br>and Migrations are fantastic. Porting ActiveRecord to squeak and<br>providing browser support for it seems like a slam dunk to me. I<br>wouldn't do a straight port but just borough the main concepts.
</blockquote><div><br>I'm still not convinced this is a good idea.<br><br>ActiveRecord is trying to solve a simple problem at its base: how can we persist massive collections of objects in Ruby? The answer they arrived at was to use an RDBMS for persistence, and then to adopt the same translation concept as a dozen other frameworks have tried: tables to classes, rows to objects, columns to instance variables. The problem is that this mapping
<span style="font-style: italic;">does not make sense<span style="font-style: italic;">.</span></span> It breaks the object model in subtle and not-so-subtle ways that ultimately become extraordinarily aggravating.<br><br>
There are whole concepts easily expressed in OO that are painfully expressed in RDBMSes at best. Trees, custom data-structures, even the whole concept of subclasses. Some of these can be worked around--recursive queries in SQL 3 permit trees, most databases let you add new data-structure by writing libraries in C, and subclasses usually can be expressed through a mix of normalizing and repeating columns across tables--but it requires effor that could be spent on getting things done, rather than simply figuring out how to persist data.
<br><br>Even Rails' migrations are a great example of a problem that RDBMSes have that Squeak does not have to have. It's basically a version-control system for the database. In Squeak, youcould simply use Monticello combined with giving your class lazy initialization. Migrations are a band-aid over the fact that relational models can't or don't express these concepts.
<br><br>Rather than try to graft objects on top of the database, I greatly prefer the idea started with ROE of bringing relational algebra to Squeak. ROE lets you cleanly write relational queries within Squeak without resorting to SQL, but deliberately makes no other attempt to unify the object and relational worlds. Though I admit this is a slightly more Lisp-like solution, I also strongly believe that it's the correct one.
<br><br>If you're writing a new application, though, why use an RDBMS in the first place? Why not figure out a way to truly persist objects? This is the solution I would like to see more Squeak users adopt. We already have two OODBMSes that we can reasonably use: GOODS, which is fast and well-tested, and Magma, which is slow but gradually improving. Rather than spending time vainly trying to get objects mapping to relational models, I'd rather spend time improving our object databases until they become truly optimal solutions for a wider class of problems.
<br><br>Having said all of that, I do understand the
need for an object-relational mapper for legacy applications, but ActiveRecord is a bad model to follow for a solution. ActiveRecord achieves its simplicity by strongly
encouraging the development of database schemas in a very particular
way, and although it is slowly gaining the flexibility to deal with
schemas that do not follow its preferred convention, there are many
other frameworks--WebObject's Enterprise Objects Framework being my
favorite--that are much better examples of legacy interfaces, if that's
the route you wish to go.<br><br>I do think it would be wonderful if Seaside had a built-in persistence mechanism as easily usable as Rails, but I would hope that the solution it ends up adopting is not ActiveRecord.<br>
<br>--Benjamin<br></div></div>