Anil wrote: > Yup, thanks. I was using it as cache as well and wanted to go step > further by having to keep some session variables in sync with SA > objects... and it seemed to have worked with just doing > obj.save_or_update() after changes.
But still, this is *really* not good practice. > But upon further reflection I can see why thats bad - imagine if > someone else changes something else in the background perhaps via an > mysql client. :) Sure, you want to keep database consistent. You could have many applications accessing your database at the same time. After all, that's what a database is used for, ACID (hehe) data sharing. So anytime you query your data from any application, you should have coherent results. From the application's point of view, you could need caching when you're requesting many times the same data to the database to lower ressource consuption. But you'll still have to deal with the issue where the data changes on the database and your application's cache still holds an out-of-date version. Depending on your priority/policy, you'd want to have some cache expiry mechanisms when the data changes on the database (eg. timeout or signal/flag if changes were made by the application itself). > Thanks! HTH, -- Alexandre CONRAD > On 5/28/07, Alexandre CONRAD <[EMAIL PROTECTED]> wrote: > >>>On 5/27/07, Anil <[EMAIL PROTECTED]> wrote: >>> >>>>user = session["user"] >>>>alert = model.Alert(form_result["name"]) >>>>user.alerts.append(alert) >>>>user.save_or_update() >>>>user.flush() >>>> >>>>I save a User SA object in session["user"] in another page. Then, in >>>>this page, I try to add Alert objects to the user object. I get this >>>>exception. >>>> >>>><class 'sqlalchemy.exceptions.InvalidRequestError'>: Object >>>>'<entic.models.Alert object at 0xcc2970>' is already attached to >>>>session '13378672' (this is '12302224') >>>> >>>>Can someone give me pointers on how I can resolve this? >>>> >>>>Plus, are there any best practices for passing around SA mapped >>>>objects in beaker sessions? >> >>Make sure you set all your User object's relations to lazy=False if >>you'll later want to access the user's alerts. This will cache the user >>object *and* it's attached alerts. >> >>Shannon -jj Behrens wrote: >> >>>I would say *don't* ;) >> >>+1 if your making modifications to your model. >> >> >>>I wouldn't expect a SA object to be serializable. It just doesn't >>>make sense to me. I don't even want to think about complications with >>>the database and ACID, nor do I want to consider the scalability >>>concerns (the SA object should be tied to a particular SA session, >>>right?). >> >>(I didn't know about the "ACID" acronym: Atomicity, Consistency, >>Isolation, Durability. Thanks. ;) ) >> >>SA was built with consistency and integrety in mind, before anything >>else. So I'm not sure you can make modifications to an 'old' User object >>because SA wants to keep track of what happens between a model and the >>database itself. So loading an old object doesn't reflect the database >>state during your current SA session. >> >>So if you want to make modifications, SA will need to load a freshly >>fetched user information from your database. >> >>I think this is how it works. >> >>I actually store my User object in the session (in cache trully for >>application wide usage) but for *read-only* purpose. I set all relations >>to lazy=False so when the user loads, it loads all it's details, >>privileges, group memberships, and group's privileges (a rather long >>generated query). I can later access from cache my user's >>.has_privilege() method to check which parts of the application should >>be displayed to the user. >> >>Regards, >>-- >>Alexandre CONRAD >> >> >> > > > > > > --------------------------------------------------------------------------------------------------- > Texte inséré par Platinum 2007: > > S'il s'agit d'un mail indésirable (SPAM), cliquez sur le lien suivant pour > le reclasser : http://127.0.0.1:6083/Panda?ID=pav_37037&SPAM=true > --------------------------------------------------------------------------------------------------- > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
