On 12/15/2011 10:25 PM, Viktor Nagy wrote: > On Fri, Dec 16, 2011 at 5:07 AM, John Anderson <[email protected] > <mailto:[email protected]>> wrote: > > On 12/15/2011 07:02 PM, Viktor Nagy wrote: >> hi, >> >> I'm stuck and sweating with a "should be simple, so common" >> problem related sqlalchemy and portable pyramid app development. >> >> I would like bind together several apps using config.include. >> All these apps use their own DBSession and Base declarations. The >> DBSession shouldn't cause any troubles as scoped session is used >> everywhere, but this is not true about the Base declarations. >> >> If I don't want to import the Base of one of my apps (it's not >> feasible in my case anyway), then I have to move every already >> defined table from other models' metadata to this Base.metadata, >> otherwise SQLAlchemy can not find related tables as they are >> contained within separate metadatas. >> >> Moreover, even when I come up with some really dirty solution and >> manage to run the pserve, the populate script needs a different >> approach just like writing tests, and it seems to me that in >> every situation I should invent new approaches, and I'm running >> out of ideas. :) >> >> I guess that overcoming such situations should be a common task, >> so I would be glad if you would share your experiences with me. >> > > I use the registry to define what session and just make sure each > Base class is defined a different name, although you could just do > import Base as base1 or something. > > So, for instance I have a the site pcolalug.com > <http://pcolalug.com> repo and it uses a re-usable library called > pyramid_signup, so in its init it registers the session to a > marker interface so pyramid_signup knows how to use it: > > > https://github.com/pcolalug/pcolalug.com/blob/master/pcolalug/__init__.py#L68 > > and the populate script just imports each base and calls create on > them: > > > https://github.com/pcolalug/pcolalug.com/blob/master/scripts/populate.py#L49 > > > Actually you avoid my problem not by using the registry, but by using > a common Base. This way it's easy! :) > > https://github.com/pcolalug/pcolalug.com/blob/master/pcolalug/models.py#L15 > > But suppose you have two projects to include and both of them create > their own Base class. (Like pyramid_signup does.) > What would you inherit from in pcolalug.models? > > The point is that Base.metadata holds all the tables that were defined > with the given Base. And when you run Base.metadata.create_all(), then > you can access only the tables know by Base. Thus foreign key > relationship can not span Bases. And this leads to serious headaches > on my side! > > > > and then in pyramid_signup, it just never uses a global session, > it just always pulls from the registry: > > > https://github.com/sontek/pyramid_signup/blob/master/pyramid_signup/lib.py#L20 > > Then to make sure that you can also override templates whenever > possible I use asset specs: > > https://github.com/sontek/pyramid_signup/blob/master/pyramid_signup/views.py#L125 > > does that help? > > > Unfortunately, it did not. :(
Look again at the code, https://github.com/pcolalug/pcolalug.com/blob/master/pcolalug/models.py#L13 and https://github.com/pcolalug/pcolalug.com/blob/master/scripts/populate.py#L54 I just don't happened to inherit from the pyramid_signup base because it has a lot of nice utilities but you *don't* have to do that, I could have just as easily inherited from Base at line 13 of models.py and all would have worked still. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
