how would u assure that noone changes these objects? it should be considered a programatical error, so throwing an exception might be appropriate. i have such concept in dbcook, and it is implemented (so far) via an assert in MapperExtension.before_insert().
u may think of such "defensive programming" approach. ciao svilen On Monday 02 June 2008 10:07:08 Nebur wrote: > Our web app needs to use an "immutable" database object structure, > i.e.some mapped classes resp.tables will change with administrative > runs only. These objects mostly are referenced by other (mutable) > persistant objects. > The structure fits well into memory and can remain in each process > for its lifetime. > > Loading these objects with any new or clear()ed session would > drastically impact performance. Even more important, these > immutable objects should be easily useable as dict keys, requiring > them to reliable keep their identity. (These objects are nice > candidates for memcached but this is not about instance identity.) > > I'm currently using this recipe: > Provide a MapperExtension with create_instance and maintain a > custom cache for the immutable objects (additionally to the > short-living identity maps of the sessions). > > class UniqueByPrikeyMapper(MapperExtension): > def create_instance(self, mapper, selectcontext, row, class_): > key = row[class_.c.id] # there's a primary key "id" always > try: > return get_instance_from_somewhere(class_, key=key) > except KeyError: # instance not in the cache: put it there > res = class_.__new__(class_) > register_instance_somewhere(class_, > key=row[instance.c.id]) > return res > > Now, any persistant instance gets cached fine when loaded. But > freshly created objects need a separate treatment. > Since we use the auto generated "id" as key, any new instance needs > to be "manually" put into the cache after is was flush()ed. I've > fiddled with a SessionExtension/after_flush(), where the new > instances can be found in flush_context.uow.new. This could be a > place to put new instances into the cache althought is seems > somewhat hackish. Alternatively, we can re-load any instance after > flush() to let create_instance() run, and throw away the original > reference. An attempt to use populate_instance() for caching > instances there (and only there) failed. populate_instance() is > *not* run when the auto- generated id is populated after flush(). > Required would be the event semantics "always called when instance > got sync'ed with the DB". > > > Someone has a better practice / comments / can see shortcomings ? > > Regards, > Ruben > > SA Version: 0.4.x > Related Links: > a recipe for unique objects, but about instance creation, not about > instance loading: > http://www.sqlalchemy.org/trac/wiki/UsageRecipes/UniqueObject > query caching thread but about performance with complex joins: > http://groups.google.de/group/sqlalchemy/browse_thread/thread/e7294 >628673aad12/6b65276bcd9e8e5a?lnk=gst&q=create_instance# > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
