Use with Flask ?

27 views
Skip to first unread message

Chmike

unread,
Dec 21, 2012, 6:34:27 AM12/21/12
to sqle...@googlegroups.com
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.

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.

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 ?

Diez B. Roggisch

unread,
Dec 24, 2012, 10:09:06 AM12/24/12
to sqle...@googlegroups.com

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
Reply all
Reply to author
Forward
0 new messages