On May 21, 2010, at 9:21 AM, Michael Bayer wrote: > > On May 21, 2010, at 9:12 AM, Michael Bayer wrote: > >> >> On May 21, 2010, at 2:11 AM, Yang Zhang wrote: >> >>> >>> It would be nice if this restriction could be lifted if explicitly >>> requested somehow (__use_pk__ = False, and have those operations raise >>> run-time exceptions if attempted). (As for why I'm using the ORM, it's >>> basically because it affords many relatively minor benefits such as >>> packaging up the tuple in its own object, a cleaner declaration syntax >>> than Table(...), no need to use table.c.blah, custom constructors and >>> methods, etc.) >> >> if you'd like to tell me what UPDATE statement should run during this >> operation: >> >> >> my_object_with_no_pk = Session.query(MyClassWithNoPk).filter(...).one() >> >> my_object_with_no_pk.some_attribute = 'new value' >> >> Session.commit() >> >> I'm all ears. > > additionally, if you'd argue that such an operation would simply be not > allowed, it still brings us no closer to determining how the identity map > would function here. The ORM is archtected around an identity map model. > The identity map is not just a "cache", its real purpose is so that objects > associated with a session are unique relative to the row they represent in > the database. > > I think here you really mean to be using the SQL expression language > directly, since if your row has no primary key you really won't get any > benefit from the ORM in any case.
Also the other features you mention like using objects to represent rows are pretty trivial to re-implement. The declarative system you like is all part of ext.declarative and follows a common metaclass model that I use for all kinds of non-ORM tasks. Table.c.blah can be avoided by just passing "c" around, but even better just implement them as descriptors on your classes - just follow the example of sqlalchemy.orm.attributes.QueryableAttribute, subclass expression.ColumnOperators and implement __clause_element__(), operate(), and reverse_operate(). The rows that come back from a result do allow attribute acccess, like row.bar, but you'd wrap around connection.execute() to return your instrumented objects in any case. It was always intended that users would create their own "micro-ORMs" for those cases where the decidedly opinionated approach of the SQLA ORM is not appropriate. This is one reason the SQL expression system is so prominent. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
