Re: Unusual default serialization for DateRangeField (django.contrib.postgres.fields.DateRangeField)

[Carl Nobile]

Are you talking about incoming data? If so you should be sending ISO aware date-time objects as such: 2019-05-12T16:27:34.503919-04:00

If you are talking about outgoing data then you should be saving in the DB aware UTC date-times as python datetime objects.

DRF will always do the right thing if you always do the above.

Aware means with the time zone.

Naive means without the time zone.

Always always always save UTC time, but not all databases let you store the time zone.

On Thu, Aug 15, 2019 at 12:35 PM Baze Blackwood <milesblac...@gmail.com> wrote:

It seems that DRF's default behavior is to stringify the object returned by DateRangeField. For example, this is how an entry appears in a "dates" field which uses this field.

"dates": "{\"bounds\": \"[)\", \"lower\": \"2019-07-19\", \"upper\": \"2019-09-14\"}",
Has anyone else experienced this behavior and/or know how to get it to preserve the object?

--
You received this message because you are subscribed to the Google Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-rest-fram...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/7947ec40-6540-455b-b2d5-85ed176fa7dc%40googlegroups.com.

--

-------------------------------------------------------------------------------
Carl J. Nobile (Software Engineer)
carl....@gmail.com
-------------------------------------------------------------------------------

[Eric Theise]

I'm working on an application that uses integers to represent years (the client assures me months and dates will never be known or used) and am having this same problem using an IntegerRangeField.

"years_produced": "{\"bounds\": \"[)\", \"lower\": \"1935\", \"upper\": \"1946\"}",

Baze, did you ever get to the bottom of your issues or, Carl, do you have any insights as to what I'm missing?

Thanks, Eric

On Thursday, August 15, 2019 at 10:13:05 AM UTC-7, Carl Nobile wrote:

Are you talking about incoming data? If so you should be sending ISO aware date-time objects as such: 2019-05-12T16:27:34.503919-04:00

If you are talking about outgoing data then you should be saving in the DB aware UTC date-times as python datetime objects.

DRF will always do the right thing if you always do the above.

Aware means with the time zone.

Naive means without the time zone.

Always always always save UTC time, but not all databases let you store the time zone.

On Thu, Aug 15, 2019 at 12:35 PM Baze Blackwood <milesblac...@gmail.com> wrote:

It seems that DRF's default behavior is to stringify the object returned by DateRangeField. For example, this is how an entry appears in a "dates" field which uses this field.

"dates": "{\"bounds\": \"[)\", \"lower\": \"2019-07-19\", \"upper\": \"2019-09-14\"}",
Has anyone else experienced this behavior and/or know how to get it to preserve the object?

--
You received this message because you are subscribed to the Google Groups "Django REST framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-rest-framework+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/7947ec40-6540-455b-b2d5-85ed176fa7dc%40googlegroups.com.

[Carl Nobile]

So I see one issue, but first, is this supposed to be a JSON object?

If so it will not parse correctly. Consider the line below.

"{\"bounds\": \"[)\", \"lower\": \"1935\", \"upper\": \"1946\"}"

                       ^

                       You have a [) which will never parse correctly, you probably want [], right?

Also single quotes (') and double quotes (") have the same meaning in Python. So '{"bounds": "[)", "lower": "1935", "upper": "1946"}'is probably better.

~Carl

On Fri, Jul 17, 2020 at 12:32 AM Eric Theise <erict...@gmail.com> wrote:

I'm working on an application that uses integers to represent years (the client assures me months and dates will never be known or used) and am having this same problem using an IntegerRangeField.

"years_produced": "{\"bounds\": \"[)\", \"lower\": \"1935\", \"upper\": \"1946\"}",

Baze, did you ever get to the bottom of your issues or, Carl, do you have any insights as to what I'm missing?

Thanks, Eric

On Thursday, August 15, 2019 at 10:13:05 AM UTC-7, Carl Nobile wrote:

Are you talking about incoming data? If so you should be sending ISO aware date-time objects as such: 2019-05-12T16:27:34.503919-04:00

If you are talking about outgoing data then you should be saving in the DB aware UTC date-times as python datetime objects.

DRF will always do the right thing if you always do the above.

Aware means with the time zone.

Naive means without the time zone.

Always always always save UTC time, but not all databases let you store the time zone.

On Thu, Aug 15, 2019 at 12:35 PM Baze Blackwood <milesblac...@gmail.com> wrote:

It seems that DRF's default behavior is to stringify the object returned by DateRangeField. For example, this is how an entry appears in a "dates" field which uses this field.

"dates": "{\"bounds\": \"[)\", \"lower\": \"2019-07-19\", \"upper\": \"2019-09-14\"}",
Has anyone else experienced this behavior and/or know how to get it to preserve the object?

--
You received this message because you are subscribed to the Google Groups "Django REST framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-rest-fram...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/7947ec40-6540-455b-b2d5-85ed176fa7dc%40googlegroups.com.

--

-------------------------------------------------------------------------------
Carl J. Nobile (Software Engineer)
carl....@gmail.com
-------------------------------------------------------------------------------

--

You received this message because you are subscribed to the Google Groups "Django REST framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-rest-fram...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/38085cbf-953c-4c56-82ed-8561ac8f4576o%40googlegroups.com.

[Eric Theise]

Hi Carl,

This is a PostgreSQL range type (https://www.postgresql.org/docs/12/rangetypes.html) and the "[)" is its standard interval; it means lower bound inclusive and upper bound exclusive. Django offers PostgreSQL-specific model fields (https://docs.djangoproject.com/en/3.0/ref/contrib/postgres/fields/#range-fields) and IntegerRangeField and DateRangeField, which prompted this thread, are both examples. You'll note Baze's dates also exhibit the "[)".  

I'm using django-filters and it knows to display the field correctly, as two inputs, but I don't understand why DRF outputs it as a string.

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/CAGQqDQ%2B_mzbqYfL9Cz4ApmqxaPf7MAuDF8MeWvv2rq-G2Sw0gQ%40mail.gmail.com.

[Carl Nobile]

Humm, interesting, I never used that functionality.

OK, so then it looks like the to_representation() method in the serializer may not be converting the type coming from the DB correctly into a JSON object, so it just gives you the raw data. You may need to override that method and convert it to JSON yourself.

So the DB field needs to match the serializer field if they don't you can get garbage. Another thing you can look at is are you using the right field type in the serializer? As I said it needs to match what is in the model. You may have to write your own serializer field type.

Some links below.

https://www.django-rest-framework.org/api-guide/serializers/#overriding-serialization-and-deserialization-behavior

https://www.django-rest-framework.org/api-guide/fields/#a-basic-custom-field

~Carl

To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/CAHnuXWjxh5Phetka3Un7ozZgcpcfSnewB6nhTHLdEWO_q3e6Wg%40mail.gmail.com.