Handler outputs id fields instead of related object

[Dave McKenna]

Hello all, I hope someone can answer something for me. I have an Entry
model that has a many to one relationship with a Day model. So a
single Day has many Entries.

class Day(models.Model):
name = models.CharField(max_length = 100)
type = models.CharField(max_length = 20, choices=DAY_CHOICES)
date = models.DateTimeField(blank=True, null=True)
slug = models.SlugField(unique=True)

class Entry(models.Model):
meal = models.ForeignKey(Meal)
day = models.ForeignKey(Day, editable=False)
meal_type = models.ForeignKey(MealType)

And handlers like this:

class DayHandler(BaseHandler):
allowed_methods = ('GET',)
model = Day
fields = ('name', 'id', 'entry_set',)

class EntryHandler(BaseHandler):
allowed_methods = ('GET',)
model = Entry

A call to /api/days/1/ produces:

{
"entry_set": "<django.db.models.fields.related.RelatedManager
object at 0x9ae23ec>",
"name": "Mon Feb 28, 2011",
"id": 1
}

and a call to /api/entries/4/ produces:

{
"meal_type": {
"_state": "<django.db.models.base.ModelState object at
0x9ae574c>",
"id": 1
"name": "Breakfast"
},
"meal": {
"name": "Potato Pancakes and Veggie Mousaka",
"dishes": [
{
"id": 4,
"name": "Vegetarian Mousaka",
"ingredients": [
{
"shrt_desc": "CELERY,RAW"
},
{
"shrt_desc": "EGGPLANT,RAW"
},
{
"shrt_desc": "LENTILS,RAW"
}
]
},
{
"id": 6,
"name": "Potato Pancakes",
"ingredients": [
{
"shrt_desc": "EGG,WHL,RAW,FRSH"
},
{
"shrt_desc": "POTATOES,RAW,SKIN"
},
{
"shrt_desc": "WHEAT FLOUR,WHOLE-GRAIN"
}
]
}
],
"id": 3
},
"day": {
"entry_set": "<django.db.models.fields.related.RelatedManager
object at 0x99b1bec>",
"name": "Mon Feb 28, 2011",
"id": 1
}
}

What I'm wondering is, how can I get

"entry_set": on /days/1/ to show the actual entry objects, instead of
a RelatedManager object.

It seems like what's happening is Piston is not "following" the
relation in the way I expect.

Any ideas?

Appreciate any help.

Thanks - Dave

[Malcolm Box]

What version of piston are you using? Using the entry_set as a field works for me here - there is explicit code in emitters.py in Emitter.constructL() to look for a related manager and spit out the queryset.

Can you stick a breakpoint in there and see why you're not getting the right behaviour?

Malcolm

--
You received this message because you are subscribed to the Google Groups "django-piston" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-pisto...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-piston?hl=en.

[Dave McKenna]

I'm using 0.2.2 with python 2.6.

I'm not exactly sure what you mean by putting in a breakpoint. I'm
thinking, put something like import pdb; pdb.set_trace() right before
I return from DayHandler.read(), but from there I'm not sure what to
look for. Any direction would be much appreciated.

Sorry - I'm a bit of a Python newb...

On Mar 14, 4:47 pm, Malcolm Box <malcolm....@gmail.com> wrote:
> What version of piston are you using? Using the entry_set as a field works
> for me here - there is explicit code in emitters.py in Emitter.constructL()
> to look for a related manager and spit out the queryset.
>
> Can you stick a breakpoint in there and see why you're not getting the right
> behaviour?
>
> Malcolm
>

[Malcolm Box]

Upgrade. 0.2.2 doesn't have the related field emitting logic.

Malcolm

[Dave McKenna]

Thanks Malcolm. I downloaded the latest source, and now I'm getting
this error: maximum recursion depth exceeded.

On Mar 15, 8:51 am, Malcolm Box <malcolm....@gmail.com> wrote:
> Upgrade. 0.2.2 doesn't have the related field emitting logic.
>
> Malcolm
>

[Justin Steward]

Each entry includes it's day which in turn includes it's entry, each of which include their day which... And so on until you hit the recursion depth. Don't include the day in the fields returned I the entry set, if that makes sense.

~ Justin

[Malcolm Box]

Alternatively, there's at least one patch floating around on the 'nets that implements a recursion stack to prevent this happening.

Malcolm

[Erik LaBianca]

I ran into the same thing, my bitbucket fork has a recursion stack that seems to work.

https://bitbucket.org/easel/django-piston

or https://bitbucket.org/easel/django-piston/changeset/f92035638c9f for just the patch.

Good luck.

--erik

[Dave McKenna]

Justin - yup you're right. Removing days does the trick.

But if I *want* days - Erik, your patch works great!

I can do what I need to do now - thanks everyone!

Dave

On Mar 15, 4:57 pm, Erik LaBianca <erik.labia...@gmail.com> wrote:
> I ran into the same thing, my bitbucket fork has a recursion stack that seems to work.
>
> https://bitbucket.org/easel/django-piston
>

> orhttps://bitbucket.org/easel/django-piston/changeset/f92035638c9ffor just the patch.

>
> Good luck.
>
> --erik
>
> On Mar 15, 2011, at 3:54 PM, Malcolm Box wrote:
>
>
>
>
>
>
>
> > Alternatively, there's at least one patch floating around on the 'nets that implements a recursion stack to prevent this happening.
>
> > Malcolm
>

> > On Tue, Mar 15, 2011 at 7:27 PM, Justin Steward <althalu...@gmail.com> wrote:
> > Each entry includes it's day which in turn includes it's entry, each of which include their day which... And so on until you hit the recursion depth. Don't include the day in the fields returned I the entry set, if that makes sense.
>
> > ~ Justin
>

> > > For more options, visit this group athttp://groups.google.com/group/django-piston?hl=en.

>
> > --
> > You received this message because you are subscribed to the Google Groups "django-piston" group.
> > To post to this group, send email to django...@googlegroups.com.
> > To unsubscribe from this group, send email to django-pisto...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/django-piston?hl=en.

[Dave McKenna]

Just realized the title of this post should have been:

"Handler outputs <RelatedManager object> instead of related object"

Can't see a way to change it - so this clarification is the best I can
do.

Dave

On Mar 15, 9:05 pm, Dave McKenna <davemckenn...@gmail.com> wrote:
> Justin - yup you're right. Removing days does the trick.
>
> But if I *want* days - Erik, your patch works great!
>
> I can do what I need to do now - thanks everyone!
>
> Dave
>
> On Mar 15, 4:57 pm, Erik LaBianca <erik.labia...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I ran into the same thing, my bitbucket fork has a recursion stack that seems to work.
>
> >https://bitbucket.org/easel/django-piston
>

> > orhttps://bitbucket.org/easel/django-piston/changeset/f92035638c9fforjust the patch.

[Malcolm Box]

I have a patch that fixes this problem ie make the fields set on the first handler overrule those set on other handlers.

Happy to share if wanted.

Malcolm

Sent from my iPhone, please excuse any typos

On 16 Mar 2011, at 19:28, Dave McKenna <davemc...@gmail.com> wrote:

> I've installed the tip, and related fields are being emitted. But for
> the example below, I noticed that the fields specified on 'entry_set'
> in the DayHandler (in this case just 'id') are being ignored. Instead
> the fields specified on the EntryHandler (in this case 'id',
> 'meal_type', and 'meal') are being emitted. And similarly, 'id' and
> 'name' are both ignored for 'meal_type' and 'meal' on EntryHandler.

>
> class DayHandler(BaseHandler):
> allowed_methods = ('GET',)
> model = Day

> fields = ('name', 'id', ('entry_set',('id',),),)

>
> class EntryHandler(BaseHandler):
> allowed_methods = ('GET',)
> model = Entry

> fields = ('id', ('meal_type', ('id','name',),), ('meal',
> ('id','name',),), )
>
> Not the end of the world, but thought I'd bring it up to see if
> there's anything that can be done to prevent the fields from being
> ignored, unless this is just the way it is with tip.
>
> Thanks - Dave

>
>
> On Mar 15, 9:15 pm, Dave McKenna <davemckenn...@gmail.com> wrote:
>> Just realized the title of this post should have been:
>>
>> "Handler outputs <RelatedManager object> instead of related object"
>>
>> Can't see a way to change it - so this clarification is the best I can
>> do.
>>
>> Dave
>>
>> On Mar 15, 9:05 pm, Dave McKenna <davemckenn...@gmail.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Justin - yup you're right. Removing days does the trick.
>>
>>> But if I *want* days - Erik, your patch works great!
>>
>>> I can do what I need to do now - thanks everyone!
>>
>>> Dave
>>
>>> On Mar 15, 4:57 pm, Erik LaBianca <erik.labia...@gmail.com> wrote:
>>
>>>> I ran into the same thing, my bitbucket fork has a recursion stack that seems to work.
>>
>>>> https://bitbucket.org/easel/django-piston
>>

>>>> orhttps://bitbucket.org/easel/django-piston/changeset/f92035638c9fforjustthe patch.

[Dave McKenna]

That would be great Malcolm, thanks.

On Mar 16, 3:54 pm, Malcolm Box <malcolm....@gmail.com> wrote:
> I have a patch that fixes this problem ie make the fields set on the first handler overrule those set on other handlers.
>
> Happy to share if wanted.
>
> Malcolm
>
> Sent from my iPhone, please excuse any typos
>

> >>>> orhttps://bitbucket.org/easel/django-piston/changeset/f92035638c9fforju...patch.

> > To unsubscribe from this group, send email to...
>
> read more »

[Dave McKenna]

I've installed the tip, and related fields are being emitted. But for
the example below, I noticed that the fields specified on 'entry_set'
in the DayHandler (in this case just 'id') are being ignored. Instead
the fields specified on the EntryHandler (in this case 'id',
'meal_type', and 'meal') are being emitted. And similarly, 'id' and
'name' are both ignored for 'meal_type' and 'meal' on EntryHandler.

class DayHandler(BaseHandler):
allowed_methods = ('GET',)
model = Day

fields = ('name', 'id', ('entry_set',('id',),),)

class EntryHandler(BaseHandler):
allowed_methods = ('GET',)
model = Entry

fields = ('id', ('meal_type', ('id','name',),), ('meal',
('id','name',),), )

Not the end of the world, but thought I'd bring it up to see if
there's anything that can be done to prevent the fields from being
ignored, unless this is just the way it is with tip.

Thanks - Dave

On Mar 15, 9:15 pm, Dave McKenna <davemckenn...@gmail.com> wrote:
> Just realized the title of this post should have been:
>
> "Handler outputs <RelatedManager object> instead of related object"
>
> Can't see a way to change it - so this clarification is the best I can
> do.
>
> Dave
>
> On Mar 15, 9:05 pm, Dave McKenna <davemckenn...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Justin - yup you're right. Removing days does the trick.
>
> > But if I *want* days - Erik, your patch works great!
>
> > I can do what I need to do now - thanks everyone!
>
> > Dave
>
> > On Mar 15, 4:57 pm, Erik LaBianca <erik.labia...@gmail.com> wrote:
>
> > > I ran into the same thing, my bitbucket fork has a recursion stack that seems to work.
>
> > >https://bitbucket.org/easel/django-piston
>

> > > orhttps://bitbucket.org/easel/django-piston/changeset/f92035638c9fforjustthe patch.

[Malcolm Box]

Here's the patch. It makes the original handler's field list overrule a field list specified on handler for a related model - which I believe to the right behaviour.

Malcolm

--- a/server/lib/django-piston/piston/emitters.py
+++ b/server/lib/django-piston/piston/emitters.py
@@ -157,10 +157,10 @@ class Emitter(object):
             if handler or fields:
                 v = lambda f: getattr(data, f.attname)
 
-                if handler:
-                    fields = getattr(handler, 'fields')   
+#                if handler:
+#                   fields = getattr(handler, 'fields')   
                
-                if not fields or hasattr(handler, 'fields'):
+                if not fields and hasattr(handler, 'fields'):
                     """
                     Fields was not specified, try to find teh correct
                     version in the typemapper we were sent.

[Dave McKenna]

Thanks Malcolm. I believe this is right too ... I'm sure I read it
somewhere but can't find where.

On Mar 17, 7:50 am, Malcolm Box <malcolm....@gmail.com> wrote:
> Here's the patch. It makes the original handler's field list overrule a
> field list specified on handler for a related model - which I believe to the
> right behaviour.
>
> Malcolm
>
> --- a/server/lib/django-piston/piston/emitters.py
> +++ b/server/lib/django-piston/piston/emitters.py
> @@ -157,10 +157,10 @@ class Emitter(object):
>              if handler or fields:
>                  v = lambda f: getattr(data, f.attname)
>
> -                if handler:
> -                    fields = getattr(handler, 'fields')
> +#                if handler:
> +#                   fields = getattr(handler, 'fields')
>
> -                if not fields or hasattr(handler, 'fields'):
> +                if not fields and hasattr(handler, 'fields'):
>                      """
>                      Fields was not specified, try to find teh correct
>                      version in the typemapper we were sent.
>

> ...
>
> read more »

[Tom Christie]

I might be reading it wrong, but possibly the same as this issue?

http://stackoverflow.com/questions/4943911/cant-exclude-foreignkey-fields-for-user-in-piston/4964093#4964093

I posted what I _think_ should be a relevant fix there.