[Seaside] Glorp and Seaside

[Ron Teitelbaum]

Hi Todd,

 

Thanks for the pointers.  

 

I saw the optimistic locking on the descriptor beLockKey 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 [mailto:tblanchard at mac.com] 
Sent: Monday, November 20, 2006 7:08 PM
To: Ron at USMedRec.com; The Squeak Enterprise Aubergines Server - general
discussion.
Cc: glorp-development at lists.sourceforge.net
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

Seaside at lists.squeakfoundation.org

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20061120/cc8c30cb/attachment.htm