On Jan 30, 1:36 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Wed, 2009-01-28 at 23:21 -0800, Vinay Sajip wrote:
>
> [...]
>
> > I was hoping there was another way. Of course subclassing's not hard
> > to do, but it means doing it for every field class. I was looking at
> > moving an application over from SQLAlchemy, which offers this feature
> > both for models and fields.
>
> That's not very natural Python behaviour, though. You can't expect to
> pass in extra arbitrary arguments to class constructors for normal
> Python classes and have them hold onto it for later collection.
>
I didn't find anything unusual about it. SQLAlchemy does this by
design [1], to allow users to attach additional meta-data, which the
SQLAlchemy team haven't thought of, to their tables and columns. In
the particular application I am looking at, this meta information is
used to control generation of test data and specific client-side UI
behaviour - it's not for the bread-and-butter case.
Their keyword arg is documented as
info – A dictionary which defaults to {}. A space to store application
specific data. This must be a dictionary.
This is available on both table and column abstractions. I certainly
found it a good way of attaching the information I needed, though of
course there are other ways it could have been done.
Regards,
Vinay
[1]
http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/schema.html#tables-and-columns
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
