>The specific problem I'm facing is model ORM objects going "stale" (the >in-memory representation is different than the database due to a change >from another machine/thread). Typically ORM layers deal with this by >supporting some form of Versioning on the records so the ORM can >freshen the cache automatically.
This is a standard problem of any database environment - as soon as you pull stuff out of the database, it's not connected to it any more (at least after you close the transaction it was connected to - PostreSQL will guaranty the validity of selected data as long as the transaction still is open). If your code is high on updates, you will have to provide a viable solution for that yourself. For example you can do the named versioning yourself by just adding a auto_now=True field to your record and compare those timestamps (the auto_now=True fields are automatically set on update time). Of course you need to check for the timestamp from the database to make sure that your cached object still is valid and yes, as long as Django doesn't have transaction control, this is not 100% reliable. After Django gets transaction control, you will be able to do the full versioning thingy in your code and might even hook that up in the manager objects that you use to access the database (read up on the manager stuff in the magic-removal branch if you are interested). bye, Georg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
