<div dir="ltr">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. <div> </div><div> > 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. </div> </div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Apr 18, 2014 at 1:45 PM, Maik Riechert <<a href="mailto:maik.riechert@arcor.de" target="_blank">maik.riechert@arcor.de</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="https://pypi.python.org/pypi/sadisplay" target="_blank">https://pypi.python.org/pypi/sadisplay</a> currently combined with pydot2. Your diagram editor (<a href="http://editor.ponyorm.org" target="_blank">http://editor.ponyorm.org</a>) 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: <a href="http://docs.sqlalchemy.org/en/rel_0_9/core/types.html#marshal-json-strings" target="_blank">http://docs.sqlalchemy.org/en/rel_0_9/core/types.html#marshal-json-strings</a>. Another example is nicer Enum's: <a href="http://techspot.zzzeek.org/2011/01/14/the-enum-recipe/" target="_blank">http://techspot.zzzeek.org/2011/01/14/the-enum-recipe/</a>. 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 <a href="mailto:ponyorm-list@ponyorm.org" target="_blank">ponyorm-list@ponyorm.org</a> <a href="/ponyorm-list" target="_blank">https://mailman-mail5.webfaction.com/listinfo/ponyorm-list</a> </blockquote></div> </div>