Thank you for the insight. However, the thing is, while this Official
Metadata is handled on an app-level basis, I'm looking for something
that will span multiple apps. (I'm thinking of projects and apps as
Django does, with projects being individual deployments and apps being
distinct packages with their own models, views, and templates. Pylons
might have a different perspective.) Do you think that having it live
in a module within the actual framework will help? (i.e.
myframework.sql) Or maybe should I create a module like that for every
project? (i.e. mysite.sqlalchemy)
On Jan 12, 8:37 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> On Jan 12, 2009, at 6:09 PM, PacSci wrote:
>
>
>
>
>
> > I've decided that for a WSGI framework I'm working on (based on
> > Werkzeug, if that helps) that SQLAlchemy will be the official ORM - as
> > in, the framework will handle the database side of the equation and
> > the user just provides the models. However, I am trying to figure out
> > how to make sure that the tables, all imported from distinct apps, all
> > use the same metadata. Whatever solution I use, I want to make sure
> > that:
>
> > - Every model is on the same, pre-bound metadata
> > - Both table/object/mapper and ext.declarative are usable
> > - It will run both on the Web and from command line tools
>
> > What I was thinking about doing was making every app have a "models"
> > function like this:
>
> > def models(metadata, AlchemyObject)
> > foo_table = Table("myapp_foos", metadata...)
> > class Foo(object): pass
> > foo_mapper = mapper(Foo, foo_table)
> > class Bar(AlchemyObject):
> > ...
> > return [foo_mapper, Bar]
>
> > But that is ugly and non-Pythonic. Does anyone know of a way that I
> > can make sure that every app is using the same metadata for its
> > models, but doesn't put too much of a burden on the users?
>
> Why not just have a blank application setup include a file, such as
> "meta.py" to quote from what Pylons does, which includes the
> "official" MetaData object to be used ? You'd put the
> declarative_base there, and potentially the engine/Session setup. A
> good idea would be to check out a Pylons 0.9.7 application and see
> what it does. You just have a few files that establish the official
> entrypoints.
>
> > (PS: Is it possible to access the underlying tables and classes from
> > mapper objects? I can't find anything about it in the docs.)
>
> the mapper has accessors on it for this stuff like class_ and
> mapped_table. There's some others too which can be gleaned from the
> source.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
