Issue #138 open

Support multiple handlers for one model

created an issue

The current behavior is to have only handler per model. A second handler defined for the same model will cause the first one to emit the same data as the second one.

I briefly looked at the code and it seems that there's a dict association model -> handler (through typemapper).

Comments (12)

  1. jonozzz reporter

    I would add another level to the typemapper which should discriminate between different handlers for the same model. And the idea is to link the resource/emitter to the typemapper.

    new_typemapper = {
        'default': default_typemapper,
        'area1': area1_typemapper,
        'area2': area2_typemapper

    Then when you define the handlers use the 'tags' to toss the handler into the right area(s):

    class CommonHandler(BaseHandler):
    class Area1Handler(BaseHandler):
    class Area2Handler(BaseHandler):

    The resource should call out the area so that it'll be able to recreate the correct typemapper by concatenating the specific area and the default one. In this case Area1Handler's emitter would 'see' only its neighbours and all in the default area.

    res1 = Resource(handler=Area1Handler, authentication=session_auth, area='area1')
    res2 = Resource(handler=Area2Handler, authentication=session_auth, area='area2')

    For the backwards compatibility if the Handler doesn't define any tags then it will go by default in the default area, and similarily if the Resource doesn't specify any area it will use the default typemapper. Also if two or more handlers for the same model go into the same area, piston should display a big warning or maybe disallow this.

    I'm not sure how this will fit into the current piston's design, you should know better. So what do you think?

  2. jonozzz reporter

    This is meant to be a quick rework of the existing functionality compatible with previous versions. The tagging idea was the easiest one that came in my mind.

    Do you or anyone else have better ideas ? I'd be glad to see them :)

  3. jonozzz reporter

    BTW, I've found another alternative which makes things much easier and cleaner.

    So here it is:

    • I created a new SQL view that does all the ugly SQL stuff and it provides the set of fields I needed.
    • Then I created a "virtual" Django model that mimics the original model but with some extra fields that I needed. I prefer to put it in a separate file called
    • I set the option managed = True. It shouldn't matter if Django doesn't see it in
    • I created a "virtual" piston handler for that model
    • Linked all them together in and everything laid up perfectly.

    This way piston can serve a read-only interface to some complex joined queries of the same base model. I use it to as a JSON provider for a UI grid control.

  4. Anonymous

    This limitation needs documenting heavily big red letters and it needs to raise an exception when you try to use the same model twice.

    I just waisted a few days of my life tracking this down.

    It appears you can hack you way around it by creating a proxy class for each handler, but I haven't tested this extensively:

    class _MyModelProxy(MyModel): pass
  5. Stephen Muss

    We have a large project which makes extensive use of piston and we have the need to use several handlers for various models.

    As one person above has mentioned, it is possible to create a proxy model which will then allow you to specify it as the handler model.

    It certainly doesn't allow for pretty code, but it is a means to get around the current limitation.

    Ideally, it would be great to see a patch which lets piston support this out of the box.

  6. Rishi Ramraj

    I've actaully patched Piston to accomodate this limitation. The fix involves introducing two new attributes to the handler; a namespace and a refereces attribte.

    It basically slices up the typemapper into different verticals, so that in any given vertical can resolve a handler for a given model without collisions. I can send you guys a patch if you like, with accompanying documentation and tests.

  7. Log in to comment