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 Item... but that's not to stop u, just a possibility.
On Tuesday 13 January 2009 14:11:42 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 -~----------~----~----~----~------~----~------~--~---
