Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

date serialization failure #648

Closed
hsolbrig opened this issue Aug 24, 2016 · 2 comments
Closed

date serialization failure #648

hsolbrig opened this issue Aug 24, 2016 · 2 comments
Labels
bug Something isn't working help wanted Extra attention is needed serialization Related to serialization.
Milestone

Comments

@hsolbrig
Copy link
Contributor

hsolbrig commented Aug 24, 2016

The following code:

import rdflib
g = rdflib.Graph()
y = ' <http://a.example/X> <http://a.example/p> "2016-01-01T00:00:00"^^<http://www.w3.org/2001/XMLSchema#dateTime>,' \
    '                                           "2016-01-01T00:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .'

p=g.parse(data=y, format="turtle")
print(p.serialize(format="turtle").decode('utf-8'))

Causes an error:

  File "...lib/python3.5/site-packages/rdflib/term.py", line 822, in __gt__
    return self.value > other.value
TypeError: can't compare offset-naive and offset-aware datetimes

This is because the serializer is trying to sort the output tuples and the two different forms of date/time can't be compared.

Recommend the following change - line 822, term.py

            if self.value != None and other.value != None:
                try:
                    return self.value > other.value
                except TypeError:
                    return str(self.value) > str(other.value)

The idea being that, if the native comparison doesn't work, fall back on the string comparison.

@joernhees joernhees added this to the rdflib 4.2.2 milestone Oct 15, 2016
@joernhees joernhees added bug Something isn't working serialization Related to serialization. help wanted Extra attention is needed labels Oct 15, 2016
@gromgull
Copy link
Member

I agree that not being able to serialise this things is very bad, but this fix introduces weird unexpected behaviour for everyone who wants semantically meaningful comparisons of literals (i.e. SPARQL)

A fix must be to pass a custom comparator into the sort call inside the serialiser, and do the fall back there.

@gromgull
Copy link
Member

same issue: #613

tgbugs added a commit to tgbugs/rdflib that referenced this issue Nov 30, 2017
This commit provides basic infrastructure for sorting Literals by value
where the underlying type has no total ordering. This provides a more
consistent solution to issues like:
RDFLib#648,
RDFLib#630, and
RDFLib#613. Where workarounds are
implemented in the serializer. This leads to massively increased code
complexity in the serializers to compensate for the fact that Literal
do not support a total ordering because of some of the underlying python
datatypes do not. The only datatype that I know of that causes this
issue at the moment is datetime, and I have implemented a fix for that.

If other types are found to have this issue the solution is to add
an entry to _NO_TOTAL_ORDER_TYPES that includes a function that
partitions the type into subtypes that do have total orders.
tgbugs added a commit to tgbugs/rdflib that referenced this issue Nov 30, 2017
This commit provides basic infrastructure for sorting Literals by value
where the underlying type has no total ordering. This provides a more
consistent solution to issues like:
RDFLib#648,
RDFLib#630, and
RDFLib#613. Where workarounds are
implemented in the serializer. This leads to massively increased code
complexity in the serializers to compensate for the fact that Literal
do not support a total ordering because of some of the underlying python
datatypes do not. The only datatype that I know of that causes this
issue at the moment is datetime, and I have implemented a fix for that.

If other types are found to have this issue the solution is to add
an entry to _NO_TOTAL_ORDER_TYPES that includes a function that
partitions the type into subtypes that do have total orders.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed serialization Related to serialization.
Projects
None yet
Development

No branches or pull requests

3 participants