views:

334

answers:

2

My app uses a "per-user session" to allow multiple sessions from the same user to share state. It operates very similarly to the django session by pickling objects.

I need to pickle a complex object that refers to django model objects. The standard pickling process stores a denormalized object in the pickle. So if the object changes on the database between pickling and unpickling, the model is now out of date. (I know this is true with in-memory objects too, but the pickling is a convenient time to address it.)

Clearly it would be cleaner to store this complex in the database, but it's not practical. The code for it is necessarily changing rapidly as the project evolves. Having to update the database schema every time the object's data model changes would slow the project down a lot.

So what I'd like is a way to not pickle the full django model object. Instead just store its class and id, and re-fetch the contents from the database on load. Can I specify a custom pickle method for this class? I'm happy to write a wrapper class around the django model to handle the lazy fetching from db, if there's a way to do the pickling.

A: 

You can overload the serialization methods. But it would be simpler to put the id and class in a tuple or dict and pickle that.

mikerobi
But if I just store the id and class in a tuple then I'm necessarily going back to the database every time I use any of the django objects. I'd like to be able to keep the ones I'm using in memory over the course of a page request. The problem is if I put them in memory, then they're gonna get pickled.How do I overload the serialization methods? I didn't see anything about that in the pickle documentation.Thanks.
muudscope
But why not just cache them? That's what Django has a cache for.
Tom
+1  A: 

It's unclear what your goal is.

"But if I just store the id and class in a tuple then I'm necessarily going back to the database every time I use any of the django objects. I'd like to be able to keep the ones I'm using in memory over the course of a page request."

This doesn't make sense, since a view function is a page request and you have local variables in your view function that keep your objects around until you're finished.

Further, Django's ORM bas a cache.

Finally, the Django-supplied session is the usual place for "in-memory objects" between requests.

You shouldn't need to pickle anything.

S.Lott
Hmm. Hadn't thought about the ORM cache. That's probably good enough for me if I just use the id/class tuple method.I need to pickle for the same reasons the session does, but the built-in session is scoped too tightly -- I have a "user-scoped" session instead of a browser-scoped session.For reasons of encapsulation it doesn't make any sense to load these objects in the view method.Anyway, thanks for the advice.
muudscope
What is a "user-scoped" session? Please update your question to explain what you're doing. How can it not make sense to do this in the view function? That's what a page request **is**.
S.Lott