Open Stack

On Mon, Jun 3, 2013 at 7:33 AM, Flavio Percoco <flavio at redhat.com> wrote:

> Hi,
>
> I'm planning to re-factor current Oslo's jsonutils module and as part
> of that re-factor process I'd like to add a better support for datetimes
> objects.
>
> Before going further with the implementation, I'd like to get some
> feedback from folks and see if any of you have already done it or at
> least thought about it.
>
> Currently jsonutils serializes datetimes using timeutils.strtime
> function, which returns a ISO8601 formatted string. Since this is a
> string, there's no easy way to understand, when de-serializing,
> whether it is a datetime, was a datetime before and / or should be
> de-serialized as datetime.
>
> The first point is:
>
> 1) Do we really need this?
>         From a "compatibiliy" POV I'd prefer not having it and avoid
>     sending datetimes that are supposed to be de-serialized. However,
>     there are definitely cases were this is useful and makes
>     implementations way easier.
>
> 2) Does it make sense to have this in Oslo?
>
>     My bet is yes. We currently need it in Glance and I think other
>     projects can benefit from this - nova does something similar. (We
>     can use Glance as a POC for this).
>
>
> 3) I've put some thoughts on it that I'd like to share:
>
>     1) Try always to convert the str to datetime - using
>     timeutils.parse_strtime. The drawback is that we might convert to
>     datetimes values that weren't datetime before being serialized.
>     Similar to what nova's sqlalchemy api does[0].
>
>     2) Add a prefix / suffix to the serialized datetime. This will
>     allow the de-serializer to know whether it should be converted to
>     datetime.
>
>     3) Serialize the datetime as a dictionary with the following
>     structure:
>
>         {"_type": "datetime",          "_value": "....",
>  "_format": "%Y-%m-%dT%H:%M:%S.%f"}
>             The above will allow the de-serializer to know whether it
>         should be converted, the object type (datetime, date or time)
>         and the format it was serialized with. I don't like this idea
>         but I see the benefit of having all that information.
>

You could also just include the _type and _value, leaving the
interpretation of that value up to the receiver.

At the summit there was a proposal in the nova track to support sending
arbitrary objects over RPC transparently as part of the versioned object
session [1]. I think the final proposal involved using a registry of types
with serializers and deserializers. Datetimes could just be another type in
that registry system.

Doug

[1] https://etherpad.openstack.org/HavanaVersionedInternalObjects


>
>
> [0]
> https://github.com/openstack/**nova/blob/master/nova/db/**
> sqlalchemy/api.py#L276<https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L276>
>
> Any thoughts / ideas?
>
> Cheers,
> FF
>
> --
> @flaper87
> Flavio Percoco
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130603/d55d4ea7/attachment.html>