Message from discussion SQLAHelper 1.0 released, and a proposal
Received: by 10.50.180.228 with SMTP id dr4mr15221836igc.3.1325136006008;
Wed, 28 Dec 2011 21:20:06 -0800 (PST)
Received: by 10.50.178.42 with SMTP id cv10ls7359418igc.2.gmail; Wed, 28 Dec
2011 21:20:00 -0800 (PST)
Received: by 10.50.168.105 with SMTP id zv9mr8331804igb.2.1325136000287; Wed,
28 Dec 2011 21:20:00 -0800 (PST)
Authentication-Results: ls.google.com; spf=pass (google.com: domain of
ahmedba...@gmail.com designates internal as permitted sender)
Received: by n13g2000prf.googlegroups.com with HTTP; Wed, 28 Dec 2011 21:20:00
Date: Wed, 28 Dec 2011 21:20:00 -0800 (PST)
X-HTTP-UserAgent: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0,gzip(gfe)
Subject: Re: SQLAHelper 1.0 released, and a proposal
From: Ahmed <ahmedba...@gmail.com>
To: pylons-discuss <firstname.lastname@example.org>
Content-Type: text/plain; charset=ISO-8859-1
> 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
Before I heard about sqlahelper, I was starting to code using this
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
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.