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 is a limited model for limited scope applications.
On Jan 13, 2009, at 7:11 AM, PacSci wrote: > > 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, yetanotherblog, and somepages. All three of those > applications have their own separate model files, yet all the created > tables need to live in Bob's one database, so they probably need to > use one metadata that's at the level of the project or the framework. > > I'm not exactly sure how the metadata works, so having one metadata > file per application might be the solution I'm working for, but I > think what's more likely is that I'll need to have the metadata to > live in framework.models.meta, because every app will need to import > their meta from one place anyway (if it's in bobsite.meta, Bob has to > rewrite every app's models file to import from bobsite.meta instead of > the site of the guy who made it to start with). > > At any rate, I think I figured out what I need to do while writing > this post. :-) So again, thank you for your insight. > > Regards, > LeafStorm > > On Jan 12, 9:48 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: >> 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 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) >> >> multiple apps (i.e. different packages) is not an issue if you make >> the "official" files local to each app. this is how pylons does it. >> If i make an app XYZ, my metadata is in xyz.model.meta. Im guessing >> you might not be considering using a "template layout" for your >> framework (i.e. like paster create). I think you should consider >> that model since I think boilerplate is a fact of life with web >> framework applications. > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
