[PonyORM-list] Things preventing me to switch from SQLAlchemy

Alexander Kozlovsky alexander.kozlovsky at gmail.com
Mon Apr 21 17:50:53 UTC 2014


Hi, Maik!
Thanks you for such a thoughtful and detailed feedback. Let me comment your
list of missing features.

> 1. Events

It's definitely on our list, but full implementation will take some time.
At the moment we have added support of three entity methods -
before_insert, before_update and before_delete. Now you can write something
like this:

    class Person(db.Entity):
        name = Required(unicode)
        age = Required(int)

        def before_insert(self):
            print 'inserting %s' % self

        def before_update(self):
            print 'updating %s' % self

        def before_delete(self):
            print 'deleting %s' % self

We pushed this to GitHub, it will be part of upcoming PonyORM 0.5 release.
The full-blown support of events (with the syntax as in your example) will
be added a bit later.


> 2. Draw the schema as an image.

We have this in our plans, but we have more urgent tasks on our list, so
were not going to add this in the near time.


> Your diagram editor is awesome, but it doesn't work offline and I cannot
create my models online due to internal policies.

We are not ready to do it right now, may be in future we'll add standalone
editor support, but for now in your case you probably have to develop
models right in code. Actually, this is not too hard, and the syntax is
quite straightforward. Anyway, there are features and options which can be
expressed in code, but have not supported by current version of editor yet.


>  Also, I really want to do it the opposite way: first write model code,
then generate diagram.

It is an interesting idea, I think we should add this functionality, but in
order to do it well we need to implement two-way synchronization between
code and diagram.


> 3. Custom types. E.g. I have a column where I store JSON and I let it
automatically marshall/unmarshall so that I only deal with the decoded JSON

We should think about custom types in general, but I'm not sure this helps
much with JSON. Currently it is possible to load JSON manually from a
string attribute like this:

    json_document = json.loads(obj.json_attr)

With custom type for JSON it will be possible to write:

    json_document = obj.json_attr

The benefit seems not so big, and this code can lead to subtle errors: if
somebody writes

    obj.json_attr["foo"]["bar"] = 123

this modification will be lost, because this change will affect just
returned deserialized JSON structure, and not attribute itself. Also, if
attribute is accessed several times, each attribute access will lead to new
deserialization of JSON value, which is ineffective.


> Enum's

This may be useful addition, but requires some time to do it right. As
Python now support standard Enum types (PEP 435) we probably should support
them, and not some custom Enum type. I expect that we add enum support in
several month, but not immediately, because work on migrations looks as
more important.


> 4. pg8000 support

As we say, it may be added in the near future, probably next week.


> 5. I don't like strings as class references (for cases where the class is
not yet defined). SQLAlchemy works around it with lambdas:
comments = relationship(lambda: Comment)

We just implemented this feature and pushed it to the GitHub. Now you can
define models as in the following example:

    class Product(db.Entity):
        name = Required(unicode)
        category = Required(lambda: Category)
        orders = Set(lambda: Order)


Thank again for your feedback. If you decide to use Pony, it will be great
if you will share your experience with us.





On Fri, Apr 18, 2014 at 1:45 PM, Maik Riechert <maik.riechert at arcor.de>wrote:

> Hi,
>
> I'm starting a new project and currently use SQLAlchemy as it seems to be
> the most recommended one. I have used SQLAlchemy just for a week now.
>
> In the past I programmed some time using C# and fell in love with LINQ. I
> thought that SQLAlchemy is pretty close to LINQ but as my queries grew
> bigger I realized it is just a nice wrapper around raw SQL and not at all
> like LINQ.
>
> Yesterday I stumbled upon Pony ORM and was impressed! I mean, that's it!
> Wouldn't it be for the nasty decompiling and AST rebuilding then that's
> definitely the way to go. And I hope Python one day gets official
> expression AST support like C# (maybe you can write up a suitable PEP?).
>
> So, currently I'm on a crossroad. Either I switch to Pony ORM, enjoy
> LINQ-style queries and give up some SQLAlchemy comfort/portability, or: I
> stay with SQLAlchemy and just suck it up and write ugly queries.
>
> Now, I'd like to list some missing features of Pony ORM (and available
> extensions etc.) in order of importance which prevent me from easily
> switching:
>
> 1. Events. E.g.:
> updated = Column(DateTime, onupdate=func.now()) , or
> @event.listens_for(User, 'before_insert')
> def ...
>
> 2. Draw the schema as an image. I use https://pypi.python.org/pypi/
> sadisplay currently combined with pydot2. Your diagram editor (
> http://editor.ponyorm.com) is awesome, but it doesn't work offline and I
> cannot create my models online due to internal policies. Also, I really
> want to do it the opposite way: first write model code, then generate
> diagram.
>
> 3. Custom types. E.g. I have a column where I store JSON and I let it
> automatically marshall/unmarshall so that I only deal with the decoded
> JSON: http://docs.sqlalchemy.org/en/rel_0_9/core/types.html#
> marshal-json-strings. Another example is nicer Enum's:
> http://techspot.zzzeek.org/2011/01/14/the-enum-recipe/.
>
> 4. pg8000 support (already mentioned in other thread)
>
> 5. I don't like strings as class references (for cases where the class is
> not yet defined). SQLAlchemy works around it with lambdas:
> comments = relationship(lambda: Comment)
>
> Please comment on these things to help me make a decision.
>
> Again, I find Pony ORM great and I hope the licensing doesn't prevent it
> from attracting more users (although I fear so). Also, I think you should
> make it clear on your website that Pony ORM currently only works for
> CPython.
>
> Cheers
> Maik
> _______________________________________________
> ponyorm-list mailing list
> ponyorm-list at ponyorm.com
> /ponyorm-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ponyorm-list/attachments/20140421/1292e78a/attachment.html>


More information about the ponyorm-list mailing list