Skip to content

Bolt V2 with point support #335

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

Merged
merged 8 commits into from
Mar 21, 2018
Merged

Bolt V2 with point support #335

merged 8 commits into from
Mar 21, 2018

Conversation

lutovich
Copy link
Contributor

@lutovich lutovich commented Mar 9, 2018

No description provided.

lutovich added 3 commits March 8, 2018 12:19
Allow driver to negotiate version 2 of the Bolt protocol and select
`Packer`/`Unpacker` based on the agreed protocol version. Struct
unpacking logic moved to the V1 unpacker. Driver initially tries to
newest available `Packer`/`Unpacker` and downgrades them after the
handshake response, if needed.
This commit makes driver able to send and receive 2D and 3D points.
Both are represented as custom `Point2D` and `Point3D` classes that
contain coordinates and coordinate reference system identifier. This
identifier comes as an integer from the database. It can thus be either
represented as `Integer` or native `number`, when
`disableLosslessIntegers` config option is set to true.
@lutovich lutovich requested a review from ali-ince March 9, 2018 14:05
lutovich added 2 commits March 9, 2018 15:12
With optional `z` component. This is more consistent with Cypher, that
does not differentiate between 2D and 3D points. It has only a single
overloaded `point()` function.
@lutovich lutovich changed the title Bolt V2 with 2D and 3D point support Bolt V2 with point support Mar 19, 2018
Copy link
Contributor

@ali-ince ali-ince left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good. There's already a build error related to TypeScript definitions.

I made a couple of small comments.

let mapper = this.structMappers[signature];
if (mapper) {
return mapper(this, buffer);
const signature = buffer.readUInt8();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense if we add size checks in existing struct unpacking logic?

* @param {number} y the <code>y</code> coordinate of the point.
* @param {number|undefined} z the <code>y</code> coordinate of the point or <code>undefined</code> if point has 2 dimensions.
*/
constructor(srid, x, y, z) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we have p1 = new Point(1, 1, 0), a 2D point after construction and later on do something like p1.z = 4 we'll end up with a 3D point. I think it would be better if we could keep point's dimensions immutable, basically deciding it in constructor and not exposing it as a public property. Does it make sense?

y: number;
z: number | undefined;

constructor(srid: T, x: number, y: number, z?: number | undefined)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having z?, do we still need | undefined?

@lutovich
Copy link
Contributor Author

@ali-ince thanks for the review! Comments should now be addressed.

@ali-ince ali-ince merged commit c637770 into neo4j:1.6 Mar 21, 2018
@lutovich lutovich deleted the 1.6-points branch March 21, 2018 11:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants