[Glorp-development] Sharing of readonly data

Hi,

This mail is part of a set of glorp questions I have (see some other
mails I've sent recently).

The topic I would like to address here is:

I have a few tables containing 'readonly' data. I would like to read in
this data once and reuse (import) it in all my separate Glorp Sessions
in the image, so that when a proxy fires, it would no longer try to read
it from the database but get it from the session's cache. Is it possible
and allowed to do this ? How would I import these objects from the
readonly session into the others ?

Thanks,
Mark

I'm kind of motivated to solve this myself.  At the moment it doesn't  
do it, but I don't think it will be too hard.  The idea, I think, is  
to tweak the cache manager to know about a shared session and, if the  
descriptor is marked readonly and shareable, then it fetches from a  
shared session.

I've also spotted the timed proxy stuff and it looks kind of neat, I  
think those could be used to good effect as well, but I'm still  
digging here looking for the best place to slide this in.

Todd Blanchard


On Dec 11, 2006, at 12:44 AM, Mark Plas wrote:

Todd Blanchard wrote:
> I'm kind of motivated to solve this myself.  At the moment it doesn't  
> do it, but I don't think it will be too hard.  The idea, I think, is  to
> tweak the cache manager to know about a shared session and, if the  
> descriptor is marked readonly and shareable, then it fetches from a  
> shared session.

Why not solve it at the application level, instead
of burdening the (already complicated) O-R framework
with this requirement.

If the data is really readonly, then at application
initialization, it could be copied into a globally
accessible place. If the data set needs caching,
then it might be easier to add a simple caching
strategy, than to dive into the O-R internals.

I thought of that - but there's the sharing aspect.  It is a seaside  
app.  I have on glorp session per web session.  But I want to share  
some data.  I'd like to register a bunch of objects as 'old' on  
startup.  I'm not quite sure what all the places are I have to do  
that.  If I just call 'registerAsOld:' on any newly create session  
with the cached objects, does this get me what I want?

The strategy I'm thinking of using is really pretty straightforward -  
add a flag to Descriptor that states that this class is  shared, and  
an attribute to glorp session called sharedSession.  If there is a  
sharedSession and the descriptor for the class is marked shared,  
delegate the fetch to the sharedSession and then register the objects  
in my session as well post fetch.  If no shared session, do what we  
do now.

Doesn't seem too complicated.  Mind you, this will work only for  
objects with no relationships to non-shared objects, and all objects  
in the class must be shared.  I think I can make it work by modifying  
half a dozen methods.

-Todd Blanchard

On Jan 3, 2007, at 8:11 PM, Yanni Chiu wrote:

At 03:02 PM 1/4/2007, Todd Blanchard wrote:

I thought of that - but there's the sharing aspect.  It is a seaside 
app.  I have on glorp session per web session.  But I want to share 
some data.  I'd like to register a bunch of objects as 'old' on 
startup.  I'm not quite sure what all the places are I have to do 
that.  If I just call 'registerAsOld:' on any newly create session 
with the cached objects, does this get me what I want?

There is no registerAsOld:. Although I think you're using an older version, so there might have been on there. I'd probably just grab the cache and add them directly.

But I think a better way, that's a bit more transparent, is that for shared classes to make a sharing cachePolicy that would go and ask the shared session for the objects rather than doing its own lookup. Or that would do its own lookup as normal, but on a cache miss would go to the shared session and see if the object was there. And I guess if it wasn't in shared, you'd want the shared session to do the actual database query - depending on whether you're assuming that all shared objects are in memory on startup, or if you only want to share them lazily once they're read in. I haven't thought that through completely, but it seems like a promising approach.

The strategy I'm thinking of using is really pretty straightforward - 
add a flag to Descriptor that states that this class is  shared, and 
an attribute to glorp session called sharedSession.  If there is a 
sharedSession and the descriptor for the class is marked shared, 
delegate the fetch to the sharedSession and then register the objects 
in my session as well post fetch.  If no shared session, do what we 
do now.

Doesn't seem too complicated.  Mind you, this will work only for 
objects with no relationships to non-shared objects, and all objects 
in the class must be shared.  I think I can make it work by modifying 
half a dozen methods.

It would be very difficult to share objects that then refer to non-shared objects. I really can't see a way to make that work without something that makes the objects appear differently in different transaction contexts.

Similarly, the advantage of doing it inside the O/R mapping is that understands how to establish the references in the first place. Otherwise, if I read an Address, and it refers to a Country, and Country objects are shared, the O/R layer has to be told somehow how to put the appropriate country in there.

-Todd Blanchard

On Jan 3, 2007, at 8:11 PM, Yanni Chiu wrote:

Todd Blanchard wrote:

I'm kind of motivated to solve this myself.  At the moment it 
doesn't  do it, but I don't think it will be too hard.  The idea, 
I think, is  to tweak the cache manager to know about a shared 
session and, if the  descriptor is marked readonly and shareable, 
then it fetches from a  shared session.

Why not solve it at the application level, instead
of burdening the (already complicated) O-R framework
with this requirement.

If the data is really readonly, then at application
initialization, it could be copied into a globally
accessible place. If the data set needs caching,
then it might be easier to add a simple caching
strategy, than to dive into the O-R internals.

At 05:31 PM 1/5/2007, Todd Blanchard wrote:

On Jan 5, 2007, at 7:54 AM, Alan Knight wrote:

There is no registerAsOld:. Although I think you're using an older version, so there might have been on there.

There is in this version :-)

I thought of the cache policy - nice placeholder - in this version it only seems to deal with expiration. 

The cache policy also controls interpretation of the cache. The cache actually holds the items, but doesn't know anything about them. In some cases they're the objects themselves, in others a collection (or maybe an association, I forget) of a time and the object.

However, the actual check for whether the object is in cache or not may or may not be possible to intercept with the current code. But I think it would be easy enough to override.

I guess I should maybe work on getting a newer port before making these changes though.

Yes, that would be good. And I'd like to get the Squeak version back in sync - mostly a matter of virtually sitting down with someone with more Squeak expertise.

-Todd Blanchard