REServe and IOSPersistent project

Dear all,

I've already posted this on the squeak-dev list, but since this is an issue for seaside developers, too, I thought posting it here could improve my chances of finding an answer.

I am evaluating some object-relational mappers for Squeak and especially Seaside applications. In addition to the obvious choice GLORP I stumbled upon the REServe/IOSPersistent project.
It seemed very promising to me, since it reduces the configuration effort to a very small amount. However, last updates have been commited in october 2006.
Does anybody know what happend to those projects and why the automated mapping idea has not been introduced in other mappers as well?

Best,

Thomas
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Thomas,

IOPersistent was reimplemented in a much cleaner fashion with  
REServe. REServe was eventually ported it PHP, minus it's query  
mechanism that implemented the Smalltalk collections protocol, and  
was released with Phaux (http://code.google.com/p/phaux/) a Seaside  
like framework for PHP. It is likely that all of that software  
continues to be used at my last place of employment but sadly no one  
appears to be maintaining and/or improving it.

Object to relational mappers are a compromise of two, largely,  
incompatible models. The idea behind REServe was to compromise the  
object model as little as possible while still maintaining some of  
the strengths of relational databases (mainly ad hock queries).  
REServe attempts to behave like an object database, root object,  
access by reference (simulated), automatic table creation, table  
migration, polymorphic data storage, etc... It also attempted to hide  
the database as much as possible.

As far was why "automated mapping" from the perspective of the  
objects defining how they are stored, the tables being created,  
migrated, and maintained from the object definitions, is not a more  
popular approach I don't know. It could be that it demands to much  
rigidity in the way tables are designed and laid out. Or that it does  
not fit well into an existing database design. It might very well be  
that people are used to creating tables, are comfortable with the  
relational model, like SQL, and think the flexibility that custom  
designed tables out weights the maintenance difficulty.

All of the open source projects and libraries I have done continue to  
excite me and spark my creativity. I encourage you to play with them  
and I hope it sparks some ideas in you.

Happy Hacking,
Will


On Apr 23, 2008, at 4:44 AM, Thomas Kowark wrote:
___________________________________
Do I dream of electric sheep?


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside