On Apr 22, 2011, at 7:18 PM, Iain Duncan wrote: > Hi folks, hoping someone can help here, couldn't figure it out from > the mapper docs. I have some mappers being created in modules that are > loaded separately. That has to stay that way, essentially our > framework has base modules that get reused and they have ZCA utilities > registered that make mappers in a make_mappers callable. This is > working well for us. What I want to do is replace or extend on of > those mapper objects in the make_mappers callable loaded from the > domain application, in a case where the base mapper utilities have > already been called. I am passing the existing dict of mappers into > each callable so they can (hopefully) be altered. In this case, for > this domain app, I need to map the User class differently to add in > new properties stored in a different table. > > make_mappers( mappers): > mappers['User'] = ( replace the User mapper here ). > > I can't just clobber mappers['User'], I get an exception that the User > class has already been mapped. Makes sense. > > Nor can I do: > > del mappers['User'] > > So I'd like to know how I can either wipe out that one mapper to > replace it with the custom version, or change the primary mapped table > to a join. I tried doing > > mappers['User'].mapped_table = join(user_table, user_extra_table) > > but that seemed to just result in loss of the original user table. > Anyone have suggestions on how I can change the mapping of the User > class *without* having to touch the module that makes the base user > mapper?
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! > 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. > -- 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.
