librelist archives

« back to archive

Database integration

Database integration

From:
Bruce Petersen
Date:
2014-11-15 @ 18:46
Greetings!


We're starting a product that uses Postgresql on the backside. I was
originally strongly considering Flask, but looking at the Falcon
architecture (with its benchmarks) is very impressive.


My only concern with setting up a prototype is integration of database
access. We're planning to use SqlAlchemy but may also use some raw
Postgresql calls. Looking at Flask and Bottle, they've provided SqlAlchemy
hooks that attach sessions to their response objects -- do you have any
such examples or could you recommend a starting point for rolling our own?


Many thanks and very best of luck in going forward!


Bruce

Re: [falcon] Database integration

From:
Kurt Griffiths
Date:
2014-11-18 @ 18:55
Hi Bruce,

I think this could be a good addition to the talons 
library<https://github.com/talons/talons>. Regardless, there are a couple 
of ways the session could be passed around :

  1.  As an additional param to the “responder” methods (on_get, on_post, etc.)
  2.  As a field in req.context (requires falcon >= 0.2)

It would be pretty straightforward to configure falcon hooks or middleware
to manage the session lifecycle. Since a new request object is created for
each request, the implementation could be as simple as:

https://gist.github.com/kgriffs/2ef0983922b890f72d8f

In this sample, each request gets a new session object that is 
automatically cleaned up after the request is routed. Since requests do 
not share context objects, this approach should be thread-safe. Also note 
that Falcon ensures post_response methods are called even when the routed 
responder raises an error.

If you would also like to be able to grab the session object from 
anywhere, without having to pass it around, you could use a scoped 
session. This gist demonstrates how that might work:

https://gist.github.com/kgriffs/b4eb14c91212f2fa3a0a

This code is just a first pass off the top of my head, and is totally 
untested, so caveat emptor! :D

—Kurt

From: Bruce Petersen 
<bruce.petersen@ironsafe.com<mailto:bruce.petersen@ironsafe.com>>
Reply-To: "falcon@librelist.com<mailto:falcon@librelist.com>" 
<falcon@librelist.com<mailto:falcon@librelist.com>>
Date: Saturday, November 15, 2014 at 12:46 PM
To: "falcon@librelist.com<mailto:falcon@librelist.com>" 
<falcon@librelist.com<mailto:falcon@librelist.com>>
Subject: [falcon] Database integration


Greetings!


We're starting a product that uses Postgresql on the backside. I was 
originally strongly considering Flask, but looking at the Falcon 
architecture (with its benchmarks) is very impressive.


My only concern with setting up a prototype is integration of database 
access. We're planning to use SqlAlchemy but may also use some raw 
Postgresql calls. Looking at Flask and Bottle, they've provided SqlAlchemy
hooks that attach sessions to their response objects -- do you have any 
such examples or could you recommend a starting point for rolling our own?


Many thanks and very best of luck in going forward!


Bruce

Re: [falcon] Database integration

From:
Bruce Petersen
Date:
2014-11-20 @ 14:00
Thank you for your thoughtful and precise reply!

I really appreciate the purity of Falcon - it fits the API philosophy
superbly.

I'll give concept a go - much appreciate the advice and the excellent
primer.

Cheers,

Bruce


On Tue, Nov 18, 2014 at 12:55 PM, Kurt Griffiths <
kurt.griffiths@rackspace.com> wrote:

>  Hi Bruce,
>
>  I think this could be a good addition to the talons library
> <https://github.com/talons/talons>. Regardless, there are a couple of
> ways the session could be passed around :
>
>    1. As an additional param to the “responder” methods (on_get, on_post,
>    etc.)
>    2. As a field in req.context (requires falcon >= 0.2)
>
> It would be pretty straightforward to configure falcon hooks or middleware
> to manage the session lifecycle. Since a new request object is created for
> each request, the implementation could be as simple as:
>
>  https://gist.github.com/kgriffs/2ef0983922b890f72d8f
>
>  In this sample, each request gets a new session object that is
> automatically cleaned up after the request is routed. Since requests do not
> share context objects, this approach should be thread-safe. Also note that
> Falcon ensures *post_response* methods are called even when the routed
> responder raises an error.
>
>  If you would also like to be able to grab the session object from
> anywhere, without having to pass it around, you could use a scoped session.
> This gist demonstrates how that might work:
>
>  https://gist.github.com/kgriffs/b4eb14c91212f2fa3a0a
>
>  This code is just a first pass off the top of my head, and is totally
> untested, so caveat emptor! :D
>
>  —Kurt
>
>   From: Bruce Petersen <bruce.petersen@ironsafe.com>
> Reply-To: "falcon@librelist.com" <falcon@librelist.com>
> Date: Saturday, November 15, 2014 at 12:46 PM
> To: "falcon@librelist.com" <falcon@librelist.com>
> Subject: [falcon] Database integration
>
>   Greetings!
>
>
>  We're starting a product that uses Postgresql on the backside. I was
> originally strongly considering Flask, but looking at the Falcon
> architecture (with its benchmarks) is very impressive.
>
>
>  My only concern with setting up a prototype is integration of database
> access. We're planning to use SqlAlchemy but may also use some raw
> Postgresql calls. Looking at Flask and Bottle, they've provided SqlAlchemy
> hooks that attach sessions to their response objects -- do you have any
> such examples or could you recommend a starting point for rolling our own?
>
>
>  Many thanks and very best of luck in going forward!
>
>
>  Bruce
>
>
>

Re: [falcon] Database integration

From:
Bruce Petersen
Date:
2014-12-02 @ 03:24
Greetings Kurt!

I've taken a close look at DB/ORM integration - the middleware suggestion
would work splendidly for SqlAlchemy.  It also looks like it could deal
nicely with raw DB where the connection handle can cross method calls.
However, when looking at PonyORM, there doesn't appear to be any reasonable
way to escape Pony's context-manager approach (where its session is wrapped
in a context manager).  Unless I'm overlooking something, how would you
feel about considering Bottle's plug-in approach?  A stack of wrappers
could actually be a nice touch / add-on for Talons. yes?  I can make a pull
request and see what you think.

Best Regards,

Bruce




On Thu, Nov 20, 2014 at 8:00 AM, Bruce Petersen <bruce.petersen@ironsafe.com
> wrote:

> Thank you for your thoughtful and precise reply!
>
> I really appreciate the purity of Falcon - it fits the API philosophy
> superbly.
>
> I'll give concept a go - much appreciate the advice and the excellent
> primer.
>
> Cheers,
>
> Bruce
>
>
> On Tue, Nov 18, 2014 at 12:55 PM, Kurt Griffiths <
> kurt.griffiths@rackspace.com> wrote:
>
>>  Hi Bruce,
>>
>>  I think this could be a good addition to the talons library
>> <https://github.com/talons/talons>. Regardless, there are a couple of
>> ways the session could be passed around :
>>
>>    1. As an additional param to the “responder” methods (on_get,
>>    on_post, etc.)
>>    2. As a field in req.context (requires falcon >= 0.2)
>>
>> It would be pretty straightforward to configure falcon hooks or
>> middleware to manage the session lifecycle. Since a new request object is
>> created for each request, the implementation could be as simple as:
>>
>>  https://gist.github.com/kgriffs/2ef0983922b890f72d8f
>>
>>  In this sample, each request gets a new session object that is
>> automatically cleaned up after the request is routed. Since requests do not
>> share context objects, this approach should be thread-safe. Also note that
>> Falcon ensures *post_response* methods are called even when the routed
>> responder raises an error.
>>
>>  If you would also like to be able to grab the session object from
>> anywhere, without having to pass it around, you could use a scoped session.
>> This gist demonstrates how that might work:
>>
>>  https://gist.github.com/kgriffs/b4eb14c91212f2fa3a0a
>>
>>  This code is just a first pass off the top of my head, and is totally
>> untested, so caveat emptor! :D
>>
>>  —Kurt
>>
>>   From: Bruce Petersen <bruce.petersen@ironsafe.com>
>> Reply-To: "falcon@librelist.com" <falcon@librelist.com>
>> Date: Saturday, November 15, 2014 at 12:46 PM
>> To: "falcon@librelist.com" <falcon@librelist.com>
>> Subject: [falcon] Database integration
>>
>>   Greetings!
>>
>>
>>  We're starting a product that uses Postgresql on the backside. I was
>> originally strongly considering Flask, but looking at the Falcon
>> architecture (with its benchmarks) is very impressive.
>>
>>
>>  My only concern with setting up a prototype is integration of database
>> access. We're planning to use SqlAlchemy but may also use some raw
>> Postgresql calls. Looking at Flask and Bottle, they've provided SqlAlchemy
>> hooks that attach sessions to their response objects -- do you have any
>> such examples or could you recommend a starting point for rolling our own?
>>
>>
>>  Many thanks and very best of luck in going forward!
>>
>>
>>  Bruce
>>
>>
>>
>

Re: [falcon] Database integration

From:
Kurt Griffiths
Date:
2014-12-15 @ 23:45
Good to know, thanks for the follow-up! I think it would indeed be helpful
to see a proof of concept for what would be needed to support PonyORM.

From: Bruce Petersen 
<bruce.petersen@ironsafe.com<mailto:bruce.petersen@ironsafe.com>>
Reply-To: "falcon@librelist.com<mailto:falcon@librelist.com>" 
<falcon@librelist.com<mailto:falcon@librelist.com>>
Date: Monday, December 1, 2014 at 9:24 PM
To: "falcon@librelist.com<mailto:falcon@librelist.com>" 
<falcon@librelist.com<mailto:falcon@librelist.com>>
Subject: Re: [falcon] Database integration

Greetings Kurt!

I've taken a close look at DB/ORM integration - the middleware suggestion 
would work splendidly for SqlAlchemy.  It also looks like it could deal 
nicely with raw DB where the connection handle can cross method calls.  
However, when looking at PonyORM, there doesn't appear to be any 
reasonable way to escape Pony's context-manager approach (where its 
session is wrapped in a context manager).  Unless I'm overlooking 
something, how would you feel about considering Bottle's plug-in approach?
A stack of wrappers could actually be a nice touch / add-on for Talons. 
yes?  I can make a pull request and see what you think.

Best Regards,

Bruce




On Thu, Nov 20, 2014 at 8:00 AM, Bruce Petersen 
<bruce.petersen@ironsafe.com<mailto:bruce.petersen@ironsafe.com>> wrote:
Thank you for your thoughtful and precise reply!

I really appreciate the purity of Falcon - it fits the API philosophy superbly.

I'll give concept a go - much appreciate the advice and the excellent primer.

Cheers,

Bruce


On Tue, Nov 18, 2014 at 12:55 PM, Kurt Griffiths 
<kurt.griffiths@rackspace.com<mailto:kurt.griffiths@rackspace.com>> wrote:
Hi Bruce,

I think this could be a good addition to the talons 
library<https://github.com/talons/talons>. Regardless, there are a couple 
of ways the session could be passed around :

  1.  As an additional param to the “responder” methods (on_get, on_post, etc.)
  2.  As a field in req.context (requires falcon >= 0.2)

It would be pretty straightforward to configure falcon hooks or middleware
to manage the session lifecycle. Since a new request object is created for
each request, the implementation could be as simple as:

https://gist.github.com/kgriffs/2ef0983922b890f72d8f

In this sample, each request gets a new session object that is 
automatically cleaned up after the request is routed. Since requests do 
not share context objects, this approach should be thread-safe. Also note 
that Falcon ensures post_response methods are called even when the routed 
responder raises an error.

If you would also like to be able to grab the session object from 
anywhere, without having to pass it around, you could use a scoped 
session. This gist demonstrates how that might work:

https://gist.github.com/kgriffs/b4eb14c91212f2fa3a0a

This code is just a first pass off the top of my head, and is totally 
untested, so caveat emptor! :D

—Kurt

From: Bruce Petersen 
<bruce.petersen@ironsafe.com<mailto:bruce.petersen@ironsafe.com>>
Reply-To: "falcon@librelist.com<mailto:falcon@librelist.com>" 
<falcon@librelist.com<mailto:falcon@librelist.com>>
Date: Saturday, November 15, 2014 at 12:46 PM
To: "falcon@librelist.com<mailto:falcon@librelist.com>" 
<falcon@librelist.com<mailto:falcon@librelist.com>>
Subject: [falcon] Database integration


Greetings!


We're starting a product that uses Postgresql on the backside. I was 
originally strongly considering Flask, but looking at the Falcon 
architecture (with its benchmarks) is very impressive.


My only concern with setting up a prototype is integration of database 
access. We're planning to use SqlAlchemy but may also use some raw 
Postgresql calls. Looking at Flask and Bottle, they've provided SqlAlchemy
hooks that attach sessions to their response objects -- do you have any 
such examples or could you recommend a starting point for rolling our own?


Many thanks and very best of luck in going forward!


Bruce