librelist archives

« back to archive

I wrote a small flask extension for managing SQLAlchemy declarative models

I wrote a small flask extension for managing SQLAlchemy declarative models

From:
Daniel Holmström
Date:
2013-04-09 @ 16:25
Hello

I wrote an extension for making it easier to handle SQLAlchemy declarative
models, https://github.com/danielholmstrom/flask-alchemyview.

I'd appreciate any feedback, especially regarding how it's packaged and 
how I handle Flask-SQLAlchemy.

The session from current_app and I wonder if that is the 'right' way to 
integrate with Flask-SQLAlchemy, 
https://github.com/danielholmstrom/flask-alchemyview/blob/master/flask_alchemyview.py#L340.

I also wonder how to get it added to the flask-extensions page.

Regards,

Daniel Holmström
holmstrom.daniel@gmail.com


Re: [flask] I wrote a small flask extension for managing SQLAlchemy declarative models

From:
Daniel Holmström
Date:
2013-04-09 @ 17:24
Thank you

I did have a look at flask-restless and I also had a version that wasn't 
based on Flask-Classy. The main reason I created Flask-Alchemy was because
I want to base the library on inheritance and I needed a frontend to a 
project that uses dictalchemy.

I wanted to base the library on inheritance is because you always end up 
with corner-cases when trying to automate these kind of things. The 
AlchemyView class is very friendly towards overriding default behaviour, 
for example it's easy to return different Colander Schemas based on the 
POST and PUT data, it supports a bsae sqlalchemy query, it supports adding
template-variables when rendering HTML that will not be present in 
JSON-responses. I choose to base Flask-AlchemyView on Flask-Classy because
it had already implemented everything I had in my own class, and more, so 
I saw no reason for keeping my own code instead of simply using 
Flask-Classy.

The reason I use dictalchemy is that it's already used in a project which 
now is getting a Flask front-end. It suits me very well since it makes it 
easy to follow relationships, both when updating models and converting 
them to dicts. With a custom JSON encoder it's also easy to put 
dictalchemy configuration directly on the model classes(o, the horror!). 
This is nice since it's possible to just call dict(self.child) and get a 
default dict representation of the child. Like it or not, it makes it very
easy to manage smaller models.

I choose colander because it's the serializing/deserializing library that 
I prefer myself. I've used WTForms before and it's not in any way bad but 
Colander was used in the project before Flask-AlchemyView was created(and 
before the web-frontend was added). What I like about Colander is that 
it's quite neutral. It serializes/deserializes but nothing else. It 
doesn't care about where the data originally came from. First I wanted to 
support different serialization libraries but there was no time so the 
colander dependencies got hardcoded, however, I don't see a big problem 
with adding support for other libraries though.

Daniel Holmström
holmstrom.daniel@gmail.com

On Apr 9, 2013, at 6:33 PM, Goran Popovic wrote:

> Awesome job with flask-alchemyView.
> 
> Did you check flask-restless? 
> It does a similar job.
> https://github.com/jfinkels/flask-restless/
> 
> Btw, any particular reason for picking Colander instead of Wtforms? 
Wtforms can be patched to accept json(ask if you need code)
> 
> I currently have no time to fully test your extension, but i will do it 
over the weekend.
> 
> Thank you for your effort
> 
> Goran
> 
> 
> On Tue, Apr 9, 2013 at 6:25 PM, Daniel Holmström 
<holmstrom.daniel@gmail.com> wrote:
> Hello
> 
> I wrote an extension for making it easier to handle SQLAlchemy 
declarative models, https://github.com/danielholmstrom/flask-alchemyview.
> 
> I'd appreciate any feedback, especially regarding how it's packaged and 
how I handle Flask-SQLAlchemy.
> 
> The session from current_app and I wonder if that is the 'right' way to 
integrate with Flask-SQLAlchemy, 
https://github.com/danielholmstrom/flask-alchemyview/blob/master/flask_alchemyview.py#L340.
> 
> I also wonder how to get it added to the flask-extensions page.
> 
> Regards,
> 
> Daniel Holmström
> holmstrom.daniel@gmail.com
> 
> 
> 
> 

Re: [flask] I wrote a small flask extension for managing SQLAlchemy declarative models

From:
Goran Popovic
Date:
2013-04-09 @ 17:48
You saved me 3-4 weeks of my life by doing this extension. I was planning
on doing something like this.

Thank you once again, i will test it over the weekend.

Btw,
Flask Classy really is a good extension.

I'm currently using Flask Classy for custom cases & Flask-Restless.
Flask restless handles relations in a weird way so if you've managed to do
it right, it's going to be super awesome

Goran


On Tue, Apr 9, 2013 at 7:24 PM, Daniel Holmström <holmstrom.daniel@gmail.com
> wrote:

> Thank you
>
> I did have a look at flask-restless and I also had a version that wasn't
> based on Flask-Classy. The main reason I created Flask-Alchemy was
> because I want to base the library on inheritance and I needed a frontend
> to a project that uses dictalchemy.
>
> I wanted to base the library on inheritance is because you always end up
> with corner-cases when trying to automate these kind of things. The
> AlchemyView class is very friendly towards overriding default behaviour,
> for example it's easy to return different Colander Schemas based on the
> POST and PUT data, it supports a bsae sqlalchemy query, it supports adding
> template-variables when rendering HTML that will not be present in
> JSON-responses. I choose to base Flask-AlchemyView on Flask-Classy because
> it had already implemented everything I had in my own class, and more, so I
> saw no reason for keeping my own code instead of simply using Flask-Classy.
>
> The reason I use dictalchemy is that it's already used in a project which
> now is getting a Flask front-end. It suits me very well since it makes it
> easy to follow relationships, both when updating models and converting them
> to dicts. With a custom JSON encoder it's also easy to put dictalchemy
> configuration directly on the model classes(o, the horror!). This is nice
> since it's possible to just call dict(self.child) and get a default dict
> representation of the child. Like it or not, it makes it very easy to
> manage smaller models.
>
> I choose colander because it's the serializing/deserializing library that
> I prefer myself. I've used WTForms before and it's not in any way bad but
> Colander was used in the project before Flask-AlchemyView was created(and
> before the web-frontend was added). What I like about Colander is that it's
> quite neutral. It serializes/ deserializes but nothing else. It doesn't
> care about where the data originally came from. First I wanted to support
> different serialization libraries but there was no time so the colander
> dependencies got hardcoded, however, I don't see a big problem with adding
> support for other libraries though.
>
> Daniel Holmström
> holmstrom.daniel@gmail.com
>
> On Apr 9, 2013, at 6:33 PM, Goran Popovic wrote:
>
> Awesome job with flask-alchemyView.
>
> Did you check flask-restless?
> It does a similar job.
> https://github.com/jfinkels/flask-restless/
>
> Btw, any particular reason for picking Colander instead of Wtforms?
> Wtforms can be patched to accept json(ask if you need code)
>
> I currently have no time to fully test your extension, but i will do it
> over the weekend.
>
> Thank you for your effort
>
> Goran
>
>
> On Tue, Apr 9, 2013 at 6:25 PM, Daniel Holmström <
> holmstrom.daniel@gmail.com> wrote:
>
>> Hello
>>
>> I wrote an extension for making it easier to handle SQLAlchemy
>> declarative models, https://github.com/danielholmstrom/flask-alchemyview.
>>
>> I'd appreciate any feedback, especially regarding how it's packaged and
>> how I handle Flask-SQLAlchemy.
>>
>> The session from current_app and I wonder if that is the 'right' way to
>> integrate with Flask-SQLAlchemy,
>> 
https://github.com/danielholmstrom/flask-alchemyview/blob/master/flask_alchemyview.py#L340
>> .
>>
>> I also wonder how to get it added to the flask-extensions page.
>>
>> Regards,
>>
>> Daniel Holmström
>> holmstrom.daniel@gmail.com
>>
>>
>>
>>
>
>

Re: [flask] I wrote a small flask extension for managing SQLAlchemy declarative models

From:
Daniel Holmström
Date:
2013-04-09 @ 18:20
The relationship management is done by dictalchemy, not Flask-AlchemyView,
so you should check out that documentation(or lack of:).
https://github.com/danielholmstrom/dictalchemy

Just a heads up, Flask-Alchemy does only handle basic stuff and this is by
design. It does not provide routes for relationships, /parent/PID/children
for example, it does not not handle composite primary keys(it could but I 
cannot decide on which URL-scheme to use and its create/update functions 
are basic.

If you have any issues this weekend please open an issue on github or send
me an email.

Daniel Holmström
holmstrom.daniel@gmail.com


On Apr 9, 2013, at 7:48 PM, Goran Popovic wrote:

> You saved me 3-4 weeks of my life by doing this extension. I was 
planning on doing something like this.
> 
> Thank you once again, i will test it over the weekend.
> 
> Btw,
> Flask Classy really is a good extension.
> 
> I'm currently using Flask Classy for custom cases & Flask-Restless.
> Flask restless handles relations in a weird way so if you've managed to 
do it right, it's going to be super awesome
> 
> Goran 
> 
> 
> On Tue, Apr 9, 2013 at 7:24 PM, Daniel Holmström 
<holmstrom.daniel@gmail.com> wrote:
> Thank you
> 
> I did have a look at flask-restless and I also had a version that wasn't
based on Flask-Classy. The main reason I created Flask-Alchemy was because
I want to base the library on inheritance and I needed a frontend to a 
project that uses dictalchemy.
> 
> I wanted to base the library on inheritance is because you always end up
with corner-cases when trying to automate these kind of things. The 
AlchemyView class is very friendly towards overriding default behaviour, 
for example it's easy to return different Colander Schemas based on the 
POST and PUT data, it supports a bsae sqlalchemy query, it supports adding
template-variables when rendering HTML that will not be present in 
JSON-responses. I choose to base Flask-AlchemyView on Flask-Classy because
it had already implemented everything I had in my own class, and more, so 
I saw no reason for keeping my own code instead of simply using 
Flask-Classy.
> 
> The reason I use dictalchemy is that it's already used in a project 
which now is getting a Flask front-end. It suits me very well since it 
makes it easy to follow relationships, both when updating models and 
converting them to dicts. With a custom JSON encoder it's also easy to put
dictalchemy configuration directly on the model classes(o, the horror!). 
This is nice since it's possible to just call dict(self.child) and get a 
default dict representation of the child. Like it or not, it makes it very
easy to manage smaller models.
> 
> I choose colander because it's the serializing/deserializing library 
that I prefer myself. I've used WTForms before and it's not in any way bad
but Colander was used in the project before Flask-AlchemyView was 
created(and before the web-frontend was added). What I like about Colander
is that it's quite neutral. It serializes/ deserializes but nothing else. 
It doesn't care about where the data originally came from. First I wanted 
to support different serialization libraries but there was no time so the 
colander dependencies got hardcoded, however, I don't see a big problem 
with adding support for other libraries though.
> 
> Daniel Holmström
> holmstrom.daniel@gmail.com
> 
> On Apr 9, 2013, at 6:33 PM, Goran Popovic wrote:
> 
>> Awesome job with flask-alchemyView.
>> 
>> Did you check flask-restless? 
>> It does a similar job.
>> https://github.com/jfinkels/flask-restless/
>> 
>> Btw, any particular reason for picking Colander instead of Wtforms? 
Wtforms can be patched to accept json(ask if you need code)
>> 
>> I currently have no time to fully test your extension, but i will do it
over the weekend.
>> 
>> Thank you for your effort
>> 
>> Goran
>> 
>> 
>> On Tue, Apr 9, 2013 at 6:25 PM, Daniel Holmström 
<holmstrom.daniel@gmail.com> wrote:
>> Hello
>> 
>> I wrote an extension for making it easier to handle SQLAlchemy 
declarative models, https://github.com/danielholmstrom/flask-alchemyview.
>> 
>> I'd appreciate any feedback, especially regarding how it's packaged and
how I handle Flask-SQLAlchemy.
>> 
>> The session from current_app and I wonder if that is the 'right' way to
integrate with Flask-SQLAlchemy, 
https://github.com/danielholmstrom/flask-alchemyview/blob/master/flask_alchemyview.py#L340.
>> 
>> I also wonder how to get it added to the flask-extensions page.
>> 
>> Regards,
>> 
>> Daniel Holmström
>> holmstrom.daniel@gmail.com
>> 
>> 
>> 
>> 
> 
>