> mappers only support the addition of new attributes after construction. > There is of course clear_mappers() but that removes the entire graph of > mappers (emphasis on graph, which is why we don't get into the surgical > removal of individual mappers). There is also the prospect of creating a > new class, which I'm assuming is not desirable here. the mapped table > itself is completely core to the mapper itself after construction. > > The real question would be , why can't your join() be created before the > mapping. I can understand this kind of issue when using declarative, but > with plain mappers you'd want all Table metadata assembled ahead of time. > > A standard strategy when this kind of issue exists is to defer the generation > of mappers, which if its more convenient can be done using your own mapper() > callable that gathers up all the various mapper() arguments into a list, then > can emit the actual mapper() calls at some later point (such as, > build_my_mappers()).
Thanks Mike. My mapper generation is actually deferred, but the point here is that the default modules build their mappers, so I can't just *extend* the base framework app if I can't replace one of it's mappers. I don't think this is such a weird pattern really, but if there is no other option, I suppose I will have to have the extension app make an explicit list of all mappers. I guess consider this a use case for why someone might want to be able to delete a mapper. I'm a bit surprised that there is no way to do so, or am I missing something? thanks Iain -- 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.
