Glorp and Seaside

All,

 

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

[hidden email]

http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I’m assuming that by “Last one wins” you mean no locking?

To be clear you are letting the basic object be read from a read only session then you are allowing changes in value holders, and then recomputing changes and applying them at commit time?  Is that right?

 

Ron

 

 

 

---

From: Todd Blanchard [[hidden email]]
Sent: Monday, November 20, 2006 7:08 PM
To: [hidden email]; The Squeak Enterprise Aubergines Server - general discussion.
Cc: [hidden email]
Subject: Re: [Seaside] Glorp and Seaside

 

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 login].

 

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.

 

-Todd Blanchard

 

On Nov 20, 2006, at 11:32 AM, Ron Teitelbaum wrote:

All,

 

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

[hidden email]

http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside