<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jul 28, 2006, at 11:17 AM, Benjamin Pollack wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">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></DIV></DIV></BLOCKQUOTE><DIV><DIV><BR></DIV></DIV></DIV>Hi folks,<BR><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Having wrestled with this problem before, I'll add a data point to each side here:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>For those show want to store objects in a relational database, Tantalus might be worth a look. It's probably not usable off the shelf, as it was written for Squeak 3.2, but it might provide a ideas and code for some new framework.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>On the other hand, I have to agree with Benjamin. Storing objects as rows works reasonably well for simple cases, but it breaks down awfully quickly when your object models start to get more complex than collections. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>On top of that, there's another, more subtle mismatch when Seaside is involved. Seaside wants objects to have long lifecycles. It tends to hang on to objects in component instance variables, link and form callbacks, and session-wide state. Even "temporary" variables tend to live a long time, since continuations can be retrieved and reentered minutes or hours after they were captured. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Databases, on the other hand want transactions to be short. "Long transactions" are a classic problem to avoid in the database world. This means that the O/R mapping layer has to be very careful about caching, managing the state of persistent objects, and detecting conflicts. It gets really tricky when you have Seaside trying to keep objects in sync with the browser on the front end, and the persistence layer trying to keep them in sync with the database on the back end. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>All this is not to say that O/R mapping can't be done, but I think it's almost impossible to do it in a way that's general enough for a wide range of applications, yet seamless and transparent for the developer. The only place I've seen it work well was when it was not transparent at all, but built in to the application and carefully crafted to have the behavior required by the application.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Colin</DIV></BODY></HTML>