On 3 Mar 2006, at 01:58, Ben Bangert wrote:
On Mar 2, 2006, at 2:27 PM, Michael Bayer wrote:
If I understand correctly from a conversation I had with Ben the other day, he wants to tack on metadata information onto class properties mostly for the purpose of providing clues to a view layer about how to handle/display that object. this is an idea I am largely uncomfortable with since the view is basically being allowed to pollute the model. also, Python allows the "tacking on" of whatever attributes you want onto any other object, including class properties, so I am not sure what kind of changes to SQLAlchemy or the declarative layer he would have in mind, that cant be better accomplished by some externally provided feature, like a special base class (ViewPollutedSQLAlchemyObject ? :) ) .
I wouldn't call it polluting. If anything, using a database "pollutes" the data you actually are representing because you are being dragged to database column types rather than expressing content fields as what they really are. Sure it might be a varchar(255), but you know its to hold Email addresses. Your model is representing SQL datatypes rather than the actual MODEL of data you want to express. You really want a Email type, and of course if you could declare that... it'd be pretty obvious both how to display and validate it.
Maybe I'm being dumb, but can't you already do this? SQLAlchemy already supports custom types for column data (so, for instance, one of my tables is returning a special UUID object based on a string column in the database).
Or is this really about syntactic sugar (i.e. making SQLAlchemy look like Django)?
