Thanks Michael. However, I also want my queries to return objects with the helpers. The rebasing method does achieve this but I am not sure how the method you are describing will.
Using mixin is interesting but it will force my applications to map them and therefore know about the table layout. Also, it potentially allows applications to add columns to the models which I do not want. Arthur On Jun 26, 9:26 am, Michael Bayer <mike...@zzzcomputing.com> wrote: > On Jun 25, 2011, at 10:59 PM, Arthur Kopatsy wrote: > > > > > > > > > > > Hi, > > > I have seen a few related questions but never a clear answer. I have a > > set of core models defined using a declarative form. These models are > > used by multiple applications. > > > In each application we however want to extend this model class with > > helper methods. Since these methods are application specific, they > > cannot be define in the model itself. > > > I have tries multiple ways with no success and all pretty gross in my > > opinion: > > 1. Subclass the original model, catch the SA load event and set > > __class__ to whatever I want. > > Problem: mapper was getting confused if the original model and the > > subclass had the same name. > > 2. Modify __bases__ and and my helper class to inject methods. > > Problem: it fails with model inheritance. > > 3. Monkey patch the module itself (models.MyModel = MyCustomModel). > > Problem: Mapper fails right away (class not mapped) > > 4. Monkey patching the class and add methods and attributes: best > > solution so far. > > > What is the recommended way? I would love to be able to subclass the > > model and tell the mapper to use that new class instead... > > If these applications run in different process spaces, and if you are able to > identify which application is running at module import time, you can achieve > this effect through careful organization of imports: > > model/__init__.py > model/some_model.py > > model/app1/__init__.py > model/app1/helpers.py > > model/app2/__init__.py > model/app2/helpers.py > > in model/__init__.py: > > if app == 'app1': > from model.app1 import helpers > elif app == 'app2': > from model.app2 import helpers > > in model/some_model.py: > > from model import helpers > class SomeWidget(Base, helpers.Widget): > # declarations > > class SomeFoober(Base, helpers.SomeFoober): > # declarations > > This might not be too different from your "inject __bases__" approach. That > should also work, if you're having trouble with inheritance you need to > inject into __bases__ only at the appropriate points, checking each target > class as to whether or not it's already part of an inheritance hierarchy. > > Another approach is to declare the model as mixins, then the individual > applications declare the actual "mapped" models using those mixins. This is > basically the same idea in the opposite direction. However that approach is > more appropriate if the model itself also varies among applications (I have > an app that does this). In this case it appears the variability is just on > the "some methods to be mixed in" side. > > > > > > > > > > > Thank you > > > Arthur > > > -- > > 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 > > athttp://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.
