[Seaside] Glorp and Seaside
tblanchard at mac.com
Tue Nov 21 00:07:53 UTC 2006
I'm about to get good at this as I'm porting an omnibase application
to use glorp. Some stuff I can tell you:
1) I tend to keep one shared read-only glorp session for most browsing.
2) I give each form its own glorp session and let the user fiddle.
If they make it through to commit, great. But then I toss it and
they get the readonly session again.
3) There is no root object. Glorp is a relational database mapper -
you query using blocks. ie
user := glorpSession readOneOf: User where: [:ea | ea login = self
4) You only have to register one object - all others get saved
through reachability and differences are calculated at commit time.
5) Everything in the session that has been registered or is reachable
from registered objects gets committed within a session. A session/
unitOfWork (to me they're like the same thing) is sort of its own
transaction context. You can save them in any order, but depending
on how you set up locking attributes, you'll either get 'last one
wins' or locking exceptions raised.
On Nov 20, 2006, at 11:32 AM, Ron Teitelbaum wrote:
> I’ve been hooking up classes to Glorp for a Seaside application.
> I’ve been reading what people have written about doing this and it
> appears that there is no support for multiple unit’s of work. The
> suggestion I found was copying model changes during commit time.
> Is this the current state of things? Do I need to serialize
> commits, and manage changes myself at commit time for seaside
> applications? I also saw a suggestion to have one unit of work, is
> this even feasible? Can we register more then one root object and
> use the commit features of glorp to keep track of changes to
> simulate multiple units of work?
> Thanks for your help!
> Ron Teitelbaum
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Seaside