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

[Feature Request]: Allow float values in Durations #768

Open
dmoree opened this issue Aug 29, 2021 · 4 comments
Open

[Feature Request]: Allow float values in Durations #768

dmoree opened this issue Aug 29, 2021 · 4 comments

Comments

@dmoree
Copy link

dmoree commented Aug 29, 2021

Description

When inserting a node with a duration property into the database, float values are truncating leaving only integer values. Both the ISO 8601 standard and Neo4j allow for decimal fractions on values so long as the decimal fraction is on the smallest unit. For example P6.5M is valid, but P6.5M4D is not.

When creating a new Duration with 6.5 months however it is stored in the database as P6M since it calls int(months) in packDuration

The driver should allow for float values on month and day if resulting in valid duration. This ideally would have an assertValidDuration that would make sure float values are not passed improperly. Float values should only be accepted on:

  • months if days seconds and nanoseconds are zero.
  • days if seconds and nanoseconds are zero.

Asserting this would make sure the resulting duration would be valid.

Steps to reproduce

  1. Start local Neo4j instance
  2. Clone repository
git clone [email protected]:dmoree/neo4j-javascript-driver-issue-duration.git
  1. Run (creates duration and uses it when adding node in database)
npm start
  1. Check output and confirm in database that duration is incorrect.

Expected behavior

The duration should be stored as P6.5M0DT0S

Actual behavior

The duration is stored as P6M0DT0S

System

Neo4j Version: 4.3.3 Enterprise
Neo4j Mode: Single instance
Driver Version: 4.3.3 (javascript)
Operating System: macOS 11.5
Node Version: 14.16.0

@bigmontz
Copy link
Contributor

Hi @dmoree,

the duration on the Neo4j drivers (not only the javascript driver) treats months, days, seconds and nanoseconds as integers. This is defined in the protocol between the database and the drivers.

How did you store/retrieve P6.5M0DT0S in Neo4j?

@dmoree
Copy link
Author

dmoree commented Aug 30, 2021

I see. I was not using any driver to store/retrieve P6.5M in the database. Rather, I was simply using Neo4j Browser to directly set a duration property on the node using both the string P6.5M (which is converted to P6M15DT18873S) and also using duration({months: 6.5, days: 0, seconds: 0, nanoseconds: 0}) (same conversion) to see how it would be stored in the database.

Using the Neo4j browser in the second way one could even specify all floats positive or negative such as duration({months: 6.5, days: -1.5, seconds: 4.5, nanoseconds: -5}) and while that wouldn't be valid as a string Neo4j will automatically translate that to a valid string (P6M13DT62077.499999995S in this case).

Is there something beyond definition in the protocol that requires the values to be integers?

@bigmontz
Copy link
Contributor

Browser uses this driver. So I will double check internally how browser is handling this data type.


I am not sure if there is something beyond the protocol definition which requires the values to be integers.

However, I'd like to know the use case of using float duration properties instead of defining using as integers. {months:6.5} vs {months:6, days: 15}.

@dmoree
Copy link
Author

dmoree commented Aug 30, 2021

I appreciate you looking into this. I thought the browser uses this driver, but wasn't sure.

The particular use case is I am trying to implement a Duration scalar in the @neo4j/graphql library (neo4j/graphql#459) whereby a user will pass as input a valid ISO 8601 duration string and the library will parse the input and use the driver to store this in the database. So ultimately, this is for completeness.

Thanks again for your time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants