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

Literal total ordering #793

Merged
merged 5 commits into from
May 14, 2018
Merged

Literal total ordering #793

merged 5 commits into from
May 14, 2018

Conversation

tgbugs
Copy link
Contributor

@tgbugs tgbugs commented Nov 30, 2017

This pull request provides basic infrastructure for sorting Literals by value where the underlying native type has no total ordering. This provides a more consistent solution to issues like: #648, #630, and #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 does not support a total ordering because some of the underlying python types do not.

The two types that currently cause issues are datetime and time, but the proposed solution is easily extensible. 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.

This pull request also adds test to ensure that types with known issues sort as expected.

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.
gYearMonth and gYear (as well as the other g* xsd types) shoud also
be included, but their current implementation does not match the xsd
spec so they are commented out. If the g* types are implemented as
durations or time intervals sorting will likely be a much more
complicated issue.
@gromgull
Copy link
Member

Thanks - it would be nice to clean-up any now unnecessary code in serializers, but that can be another PR!

@gromgull gromgull merged commit 550341f into RDFLib:master May 14, 2018
tgbugs added a commit to tgbugs/rdflib that referenced this pull request May 14, 2018
This merge includes the changes from

RDFLib#663
RDFLib#793
RDFLib#827

which were branches

tgbugs:fix-uri-spec
tgbugs:total-order-patch
tgbugs:closed-namespace-attribute-error

respectively.
@RDFLib RDFLib deleted a comment from coveralls Oct 27, 2018
@RDFLib RDFLib deleted a comment from coveralls Oct 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working in-resolution SPARQL
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants