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.
Anyways, its a different layer entirely, where the ORM is for working
with the database, the Model I'm envisioning is another layer of
abstraction above. It's quite likely a declarative layer wouldn't
even apply to what I'm talking about as it'd be more prudent to have
a specialized metaclass build the SQLAlchemy backed object.
The syntax I'm envisioning is more similar to Django (though with the
power of SQLAlchemy), ala:
class Person(....):
name = field.Char(length=50)
email = field.EmailAddress(not_empty=True)
joined_on = field.DateTime()
The metaclass would use data from each field object to use the
appropriate SQLAlchemy column type, and since the field types are
descriptive of the data they represent, rather than how a database
stores it; they can be used to setup default validation for the
fields, hints for how the field is represented, etc. I'd consider
this all 'Model' behavior, but definitely outside the scope of
SQLAlchemy as an ORM.
If anyone else is interested in a more generalized Model layer like
this, feel free to drop me a personal email.
Cheers,
Ben
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
