Pyramid with SQLAlchemy

[Silviu Dicu]

For older versions of pyramid the setup for sqlalchemy session was done with scooped_session similar to this

DBSession = scoped_session(
    sessionmaker(
        autoflush=True,
        expire_on_commit=False,
        extension=zope.sqlalchemy.ZopeTransactionExtension()
    )

However I see that newer tutorials as well the pyramid docs 'promotes' sqlalchemy with no threadlocals where the DBSession is attached to the request object.

Is the 'old' way broken and what is the advantage of the no threadlocals ?

thanks!

ps: posted as well http://stackoverflow.com/questions/40922933/pyramid-with-sqlalchemy 

[Mikko Ohtamaa]

Hi Silviu,

The old pattern is not broken if you don't change anything. However it assumes 1 request = 1 dbsession = 1 thread pattern which is conceptually not correct. Occurences where this may fail include

* Multiple dbsessions (e.g. one read-only for faster dbsession access)

* Async io web servers

* Celery task queues that run multiple tasks under a same worker thread

* Unit testing: multiple tests under the same thread

Thread locals are not very welcome pattern by many senior developers. Overusing it results to harder to maintain, harder to test, code. It is adviced to explicitly pass dbsession around when needed, or encapsulating your code to classes that take the current dbsession as a constructor argument.

Cheers,

Mikko

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/4413dd47-971b-41af-9fda-f82574c2d62f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Mikko Ohtamaa
http://opensourcehacker.com
http://twitter.com/moo9000

[Silviu Dicu]

Makes sense - thanks.

On Friday, 2 December 2016 03:33:43 UTC-5, Mikko Ohtamaa wrote:

Hi Silviu,

The old pattern is not broken if you don't change anything. However it assumes 1 request = 1 dbsession = 1 thread pattern which is conceptually not correct. Occurences where this may fail include

* Multiple dbsessions (e.g. one read-only for faster dbsession access)

* Async io web servers

* Celery task queues that run multiple tasks under a same worker thread

* Unit testing: multiple tests under the same thread

Thread locals are not very welcome pattern by many senior developers. Overusing it results to harder to maintain, harder to test, code. It is adviced to explicitly pass dbsession around when needed, or encapsulating your code to classes that take the current dbsession as a constructor argument.

Cheers,

Mikko

On 2 December 2016 at 02:58, Silviu Dicu <silvi...@gmail.com> wrote:

For older versions of pyramid the setup for sqlalchemy session was done with scooped_session similar to this

DBSession = scoped_session(
    sessionmaker(
        autoflush=True,
        expire_on_commit=False,
        extension=zope.sqlalchemy.ZopeTransactionExtension()
    )

However I see that newer tutorials as well the pyramid docs 'promotes' sqlalchemy with no threadlocals where the DBSession is attached to the request object.

Is the 'old' way broken and what is the advantage of the no threadlocals ?

thanks!

ps: posted as well http://stackoverflow.com/questions/40922933/pyramid-with-sqlalchemy 

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/4413dd47-971b-41af-9fda-f82574c2d62f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.