Thanks, I'll explore your suggestion. I'm using MySQL as a database. The one thing I liked about zope was the transparent persistence that ZOBD gave. Now I have to think about persistence. On the other hand, working with Pylons is like you feel when you take off a 50lb backpack!
On Feb 7, 8:00 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote: > On Feb 7, 2008 7:53 AM, Richard <[EMAIL PROTECTED]> wrote: > > > > > > > Hi, I'm trying to escape the zope monster and so I started to play > > with Pylons as a possible solution. I find its simplicity really > > appealing and, in general, I like it a lot. > > > However, I'm having a bit of a problem with the paradigm shift and > > need some guidance. I am planning to build an app. which consists of a > > number of business objects in a hierarchy. This hierarchy provides > > info and context which users can explore in a stateful-manner. If I > > have understood Pylons correctly, each http request will effectively > > result in my object hierarchy being set up and then torn down, with > > all the overhead this entails. What I think I want is to set up a user > > session, during which the object hierarchy persists. When the session > > is closed, hierarchy is torn down. During the session, any data > > changes are reflected in the model¦database. What is the Pylons way to > > do this? any pointers as to how I should go about it? I only need an > > outline, I can probably rtfm to get the details. > > I would store it all in the session; then your data management effort > is nil. You can put anything picklable in the session, like a > hierarchy of state objects. You didn't mention which database you're > using, but here are my guesses: > > SQLAlchemy ORM: not sure if you can persist ORM records directly, but > if you "detach" them from the database session you'll have better > luck. You'd then have to reattach them to modify the database. > > Durus & ZODB: not sure if you can put persistent objects directly into > the session, but at worst you'd just have to copy the attributes to > identical objects that don't subclass persistent. But you can also > just leave them in the database itself, keyed by session ID. > > -- > Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
