[PATCH] Explicitly specified but empty fields are ignored

Issue #114 open
David Wolever
created an issue

For example: {{{ class Foo(Model): bar = []

class FooHandler(BaseHandler): model = Foo fields = ('bar', )


When the FooHandler is called upon to read Foos, the 'bar' attribute will not be included in the results.

I've got a fix + unit tests here: http://bitbucket.org/wolever/django-piston/changeset/fb347968f4f5/

Comments (10)

  1. Halldór Rúnarsson

    Oh, I'm so sorry. Looks like I just had old version of piston, I'm running the latest "release" which does not have that change (upgrading is no problem). This fixes the problem I had; where there is an empty string. Don't know whether there might be cases where the data returned from the ORM is actually None and should be returned as null value.

  2. Halldór Rúnarsson

    I recreated a simple test that reproduces exactly the kind of problem I had (inherited models and stuff) and fixed it in a bit more pythonic way (IMHO) by using try/except NameError here:


    I also had a problem with the UnitTests, the test_incoming_json stuffs didn't quite work for me (probly because of some formatting issues) so I parsed the output to python and compared it to python data structures. I don't care how you fix it but doing something would be really nice.

  3. Denis Ryzhkov

    Seems like development of the Piston had stopped a year ago.

    Here is one more quick patch of piston/emitters.py:

    @@ -212,8 +212,8 @@
                             ret[maybe_field] = _any(met_fields[maybe_field](data))
    -                        maybe = getattr(data, maybe_field, None)
    -                        if maybe:
    +                        if hasattr(data, maybe_field):
    +                            maybe = getattr(data, maybe_field)
                                 if callable(maybe):
                                     if len(inspect.getargspec(maybe)[0]) == 1:
                                         ret[maybe_field] = _any(maybe())
  4. Joshua Ginsberg

    Also, to honor backward compatibility, I'm inclined to leave the default behavior alone (fields that are None will be ignored) but can be overridden at the Resource level with a class-level attribute (fields that are None will be null).

  5. Log in to comment