On Nov 22, 2010, at 12:21 PM, Dan Ellis wrote: > > > If I use properties with the same names as the columns, how can I > avoid them clobbering the actual columns? I did try subclassing > DeclarativeMeta to enforce column_prefix='_', but it I think I > misunderstood what that does, because it made query(BlogPost).get(...) > complain about the DB not having an _id field. Does column_prefix > change what SA expects the DB columns look like, or just the names of > the attributes?
So the traditional approach is synonym(), which yeah involves naming the column with the underscore, and theres a helper in declarative for that. Synonym() is being superceded in 0.7 by hybrid attributes, which you can take a look at in 0.6 in the examples/derived_attributes/ example. The ad-hoc placement of synonym or a @hybrid doesn't scale up well for when you want every attribute to have the same thing happening. With declarative, you can augment the mapper() function used to create a mapping, if I wanted to do the underscore thing _ and automatically generate descriptors for all attributes I'd probably use that hook. That is __mapper_cls__ on the declarative class or the "mapper" argument to declarative_base(). I'd avoid the usage of a custom metaclass if possible, tends to be too brittle. There's also a hook you can get when the descriptors are being placed on the class. This hook is also being modernized in 0.7, but you can experiment with the 0.6 version using the example in examples/custom_attributes/listen_for_events.py, which illustrates the placement of AttributeExtensions on all classes (in 0.7 this will look like "event.listen(myfunc, "on_set", InstrumentedAttribute)"). But using that same example, you could instead replace all the attributes being instrumented with a custom subclass of orm.attributes.InstrumentedAttribute that does what you want on __get__(), __set__(), __del__(). Just saying attr.__class__ = MyCustomAttribute against the existing object would achieve that. That should be pretty easy and non-intrusive, and can still be directed at just certain target attributes. Another way to implement a system where one master function is receiving keys and values, you can use __getattribute__() and __setattr__(). If I really had a generic key/value/roles system in place, I might choose that. -- 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.
