On Sep 22, 2013, at 11:47 PM, Donald Stufft <[email protected]> wrote:
> Mostly I'm trying to avoid global state like metadata.
irony....the purpose of MetaData is to *avoid* global state. If any Table
could refer to ForeignKey("someothertable.id"), without MetaData it means
SQLAlchemy would need to have a truly global registry of all tables everywhere
(it would also be disastrous as far as naming in large and/or multi-tenancy
style apps). It would also make create_all() etc. very painful.
> The Tables themselves are global, but I feel like the metatdata maybe
> shouldn't be?
MetaData and Table are both objects. Feel free to put them in some context
that you pass around everywhere. MetaData itself has all the Table objects
inside of metadata.tables too.
I never really write Core-only apps in the first place (since it sounds like we
aren't talking about any mapped classes) so I don't know that there's really an
official pattern here. Of course historically, having Table objects as
global seems fairly natural but I'm not as allergic to "global" state as other
folks.
> I'm not a SQL alchemy expert so maybe what I'm trying to do is crazy and the
> answer is don't do that. Mostly I'm trying to figure out what patterns are
> best for testable apps written with SQL alchemy.
yeah pretty soon I'm going to have to full on go after this "global == not
testable" thing. I see no evidence for this at all, and the "globals aren't
testable" orthodoxy makes the incredibly common and useful registry pattern
(http://martinfowler.com/eaaCatalog/registry.html) not really possible. My
Pycon talk in 2014 (assuming it's accepted) will illustrate some simple test
patterns where global Session registries are involved.
signature.asc
Description: Message signed with OpenPGP using GPGMail
