> Any library that
> utilizes a shared global is just asking for problems when two independent
> packages want to use that library.
I am interested to know the answer to Michael's question. The problem
is not multiple bases or sessions, which is to be addressed in Mike's
V2 api. It is about multiple apps/packages accessing sqlahelper.
> Without it
> I would expect the library to dynamically define the User class based on a
> Base and Session that I supply to it, it would then return me the new User
> class using that Base.metadata, and I could track that User class within my
> app.
Before I heard about sqlahelper, I was starting to code using this
approach.
However, the way sqlalchemy functions now, makes it impossible to go
further with this approach if you will be using relationships. (Mixins
were a great addition to sqlalchemy 0.7 which gives us more
flexibility to using sqlalchemy as a third party lib. However, there
are still missing bits.)
I wouldn't have resorted to sqlahelper if not for two things (might be
actually one):
groups = relationship("Group", secondary=user_groups_table)
the secondary argument only accepts passing a Table object. if it
accepts a string (a table name to look up, for example, that is
evaluated at mapping time) I wouldn't have resorted to
passing my base around. The obstacle is that to build a table you have
to have your base at hand.
Table('tablename', base.metadata, Column('column'))
Otherwise putting a "complete" auth schema in a third party library
won't be feasible, unless you leave out the tables and relationships,
which kind of defeats the purpose.
I wonder if it is ok for sqlalchemy either to accept a string for the
secondary argument or to code a Table schema that gets attached later
to a base metadata. This would add more flexibility to sqlalchemy, to
be used in third party libraries.
I want to hear what Mike Bayer thinks about this.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
