On Dec 21, 2012, at 12:34 PM, Chmike wrote: > Hello, > > I'm new to Flask and Elexir and I'm writing a small web app using Flask and > jQueryMobile. I would like to use Elixir as backend database API instead of > SQLAlchemy because it's so simple. > I've implemented the small Flask app with a login popup that works and I have > implemented the Elixir model file that works as well but independently of > Flask. > > I would now like to be able to use the Elixir model with my Flask app. > Unfortunately I couldn't find any documentation or code example on line how > to do so. > One of the problem is with the session variable clash. One is instantiated by > Flask to carry web session related information and one is instantiated by > Elixir to carry db related session information.
You should IMHO keep these two separate. DBSession is for request-bound state. Sessions are for state that spans several requests. As a DB is usually used with a transactional pattern, it doesn't work well for both cases. So don't try & stuff DB-objects themselves into the session. If you have to, put keys in there, or make some kind of middlewar/filter that refreshes "stale" ORM-objects in the session before starting to (re)use them in the actions of your webapp. > > What I also would like to know is how the classes instances are managed. > > Could we keep the instantiated classes mapped to the db content across > requests ? This is to use them as a cached version of db information. How do > we ensure the cache doesn't overflow if the number of classes becomes too > big. I mentionad a way to accomplish that earlier, but I doubt there are any LRU-mechanisms already present within SA or Elixer. And if you really are wary about this, then don't try & cache full instances, but instead only enough state to re-create the ORM objects. You might also consider caching plain python structures, maybe even as JSON-structures within a memecached. > > Considering this documentation: > http://flask.pocoo.org/docs/patterns/sqlalchemy/ I see this piece of code > > @app.teardown_request > def shutdown_session(exception=None): > db_session.remove() > > Which I guess flushes the session objects in the session object. Could we > avoid this ? It does, and you shouldn't remove it because I guess if you do, you might end up with statements not being propagated to the DB and not having a proper transactional boundary. But this is just guessing, read on the docs of sqlalchemy what DBSession.remove really does. All in all, don't worry about caching for now. Make transactions around requests, and re-fetch data from the DB. Until you can *prove* by profiling that certain db-ops are dragging the web-app down, it's premature optimization anyway. Diez -- You received this message because you are subscribed to the Google Groups "SQLElixir" 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/sqlelixir?hl=en.
