Re: Serialize model properties enhancement

2007-04-29 Thread Russell Keith-Magee

On 4/28/07, David Elias <[EMAIL PROTECTED]> wrote:
>
>
>
> On Apr 28, 2:48 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
> > The open question in my mind is where the serialized data goes - do we
> > put it into the fields block, or do we start a new 'extra' block? i.e,
> > which of the following JSON outputs would you expect?
>
> I prefer the latter too, with the extra block.
>
> > And what happens on deserialization? Is the attribute restored, or
> > ignored? I'm inclined to prefer the latter serialization format, and
> > ignore on restoration, but I'd be interested in hearing other
> > opinions.
>
> Regarding deserialization, i guess if a queryset will set these extra
> columns to a model why not restore them?

Two reasons - one practical, one philosophical.

Practical: If you go down Oyvind's path, and serialize a property that
has a getter, but not a setter, you could get some interesting
fireworks on reserialization.

Philosophical: The purpose of deserialization is to get data back into
the database. Since the 'extra' attributes won't/can't ever be saved
to the database, my gut reaction is that we should avoid the
appearance that these extra attributes are 'normal' in any way -
refusing to deserialize them is just one way of achieving this
separation.

Yours,
Russ Magee %-)

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



Re: Serialize model properties enhancement

2007-04-28 Thread David Elias



On Apr 28, 2:48 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> The open question in my mind is where the serialized data goes - do we
> put it into the fields block, or do we start a new 'extra' block? i.e,
> which of the following JSON outputs would you expect?

I prefer the latter too, with the extra block.

> And what happens on deserialization? Is the attribute restored, or
> ignored? I'm inclined to prefer the latter serialization format, and
> ignore on restoration, but I'd be interested in hearing other
> opinions.

Regarding deserialization, i guess if a queryset will set these extra
columns to a model why not restore them?

David Elias


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



Re: Serialize model properties enhancement

2007-04-27 Thread Russell Keith-Magee

On 4/28/07, David Elias <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee escreveu:
> > On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I'm afraid I don't see the benefit of what you are proposing. The
> > serialization framework exists for the easy serialization of Django
> > DB-backed objects - not for the arbitrary serialization of _any_
> > object, and derived properties like the ones you are highlighting as
> > examples don't add anything to the serialized representation of a
> > DB-backed object.
>
> Sorry for bringing this again.
>
> And what about queryset's extra_select dictionary? imo makes sense,
> since we pass a queryset to the serializer.
>
> What's your opinion?

Ok; this is a different use case. You're talking about attributes on
the model that have been derived from the database, and are augmenting
the normal results from the query set. This is a use case that has
some value.

My initial reaction on how to implement this would be to mirror the
QuerySet API; add an 'extra' argument, which allows you to specify
attributes that you want to have serialized.

The open question in my mind is where the serialized data goes - do we
put it into the fields block, or do we start a new 'extra' block? i.e,
which of the following JSON outputs would you expect?

[
  {
"pk": "1",
"model": "auth.user",
"fields": {
  "username": "jsmith",
  "first_name": "John",
  "last_name": "Smith",
  "my_extra_select": "mydata"
}
  }
]

or

[
  {
"pk": "1",
"model": "auth.user",
"fields": {
  "username": "jsmith",
  "first_name": "John",
  "last_name": "Smith"
},
"extra": {
  "my_extra_select": "mydata"
}
  }
]

And what happens on deserialization? Is the attribute restored, or
ignored? I'm inclined to prefer the latter serialization format, and
ignore on restoration, but I'd be interested in hearing other
opinions.

Yours,
Russ Magee %-)

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



Re: Serialize model properties enhancement

2007-03-20 Thread Russell Keith-Magee

On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I am in no way saying this should be default behaviour of the
> serializers, but as a option, making a own serializer for theese cases
> is possible, but this makes it a lot of more work for something that
> could be so DRY.

Again, what you are proposing (and your example) is very explicitly
_not_ DRY. In this example, the preview property repeats data that is
held canonically in the image attribute. DRY would dictate that you
use the image attribute, rather than serializing a completely derived
attribute.

I'm afraid I don't see the benefit of what you are proposing. The
serialization framework exists for the easy serialization of Django
DB-backed objects - not for the arbitrary serialization of _any_
object, and derived properties like the ones you are highlighting as
examples don't add anything to the serialized representation of a
DB-backed object.

For the use-case you describe - XMLRPC and similar calls - you need to
adhere to a specific API. It would expect it to be very unusual for
the requirements of an RPC API to match the serialization strategy of
a Django object. For these problems, you need to serialize a very
specific set of object-related information (not the object itself) in
a very specific format; the better approach in this cases would be to
construct a dictionary that explicitly contains the data you want, and
use the SimpleJSON/PyYAML/XML libraries natively to serialize the
dictionary into the desired format.

Yours,
Russ Magee %-)

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



Re: Serialize model properties enhancement

2007-03-16 Thread [EMAIL PROTECTED]

It is really great for including get_FOO_url or getting data from
related models without making custom serializers when serializing to
json or xml for xmlhttp requests.

class Gallery(models.Model):
name = models.CharField()

def _preview(self):
try:
   image = self.image_set.all()[0].get_preview_url()
except:
image = None
return image

 preview = property(_preview)

class Image(models.Model):
gallery = models.ForeignKey(Gallery)
preview = models.ImageField(upload_to='foo')

I am in no way saying this should be default behaviour of the
serializers, but as a option, making a own serializer for theese cases
is possible, but this makes it a lot of more work for something that
could be so DRY.

On 16 Mar, 23:41, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
>
> > I think the serializers should have a option for serializing model
> > properties
>
> > This is set to design decision needed, does this seem like something
> > django needs?
>
> >http://code.djangoproject.com/ticket/3661
>
> In the example you give on this ticket, the property myattr is
> directly derived from the database value mydescription - I can't see
> any value in serializing both values.
>
> Even if the property wasn't a simple derivation of the database value
> - if data isn't part of the database definition, it will be extremely
> transient, and as soon as the instance is lost, so is the property
> data. Again, I can't see any value in making that data a permanent
> part of a serialized representation.
>
> Am I missing something here?
>
> Yours,
> Russ Magee %-)


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



Re: Serialize model properties enhancement

2007-03-16 Thread Russell Keith-Magee

On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I think the serializers should have a option for serializing model
> properties
>
> This is set to design decision needed, does this seem like something
> django needs?
>
> http://code.djangoproject.com/ticket/3661

In the example you give on this ticket, the property myattr is
directly derived from the database value mydescription - I can't see
any value in serializing both values.

Even if the property wasn't a simple derivation of the database value
- if data isn't part of the database definition, it will be extremely
transient, and as soon as the instance is lost, so is the property
data. Again, I can't see any value in making that data a permanent
part of a serialized representation.

Am I missing something here?

Yours,
Russ Magee %-)

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



Serialize model properties enhancement

2007-03-16 Thread [EMAIL PROTECTED]

I think the serializers should have a option for serializing model
properties

This is set to design decision needed, does this seem like something
django needs?

http://code.djangoproject.com/ticket/3661


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