I've run into some difficulty getting the ORM to fit into an existing code base with some, I suppose, non-standard conventions.
One of the conventions is to not allow primary keys (auto-incremented integers) to be exposed on the front-end servlet or template but to maintain the original integer values inside 'logic' or 'back- end' code. We've been through a few methods of trying this, but they feel like we're fighting sqlalchemy and must be missing something. The plan is to flip a flag when the object passes through a pre- defined barrier, converting these columns only when they are asked for. The original implementation had us creating two columns, one of them being a synonym which provides the encryption behavior, but this means we have class that look like this: class Foo(Base): id, _id = build_id_column(Integer, primary_key=True) The second implementation is attempting to get rid of the dual columns by redefining the underlying descriptor, which children of ColumnProperty() provide (like SynonymProperty()) but basic ColumnProperty seems to ignore. So I had to sub-class ColumnProperty, redefine instrument_class() and then re-implement register_descriptor() to achieve. This is all getting very complicated. Is there any other way to get some control over getting of a column ? AttributeExtension handles the setting, I think, but there is no interface for getting. I'm hoping I'm missing something. (Using sqlalchemy 6beta1 and declarative) Thanks, Rhett -- 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.
