No, I'm going to use a template layout. I'm not sure how I'm going to
organize it is clear to you, so it might be better to give an example:
Say Bob has a Web site, so he creates a project named bobsite. For the
site, he finds three applications other people have written -
aguestbook,
may or may not be relevant, those n- apps may have same-named tables
that have nothing to do with each other, e.g. Item.
so either separate metadata's or separate schema's if they are
supported... and the latter is not easily made transparent into the
apps - if they all expect a table called
the metadata is just a dictionary, and is basically a namespace where
a program can find Table objects based on their name. it should be in
as narrow a scope as possible, and should not be considered to have
any relationship to a database engine or connection - its ability in
that regard
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,
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
On Jan 12, 2009, at 9:15 PM, PacSci wrote:
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
