[Seaside] Glorp and Seaside

[Todd Blanchard]

On Nov 20, 2006, at 5:32 PM, Ron Teitelbaum wrote:
> I’m assuming that by “Last one wins” you mean no locking?
Yes - total free for all.
> 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?

My strategy is for viewers to use the shared read only session, but  
each form (where you are potentially going to be doing updates) works  
off of its own glorp read/write session.  These read/write sessions  
are short lived and then tossed.  It saves having to revert changes.

>
>
> 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/8b1d08b2/attachment-0001.htm