Skip to content

1.0 record #42

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 5 commits into from
Mar 18, 2016
Merged

1.0 record #42

merged 5 commits into from
Mar 18, 2016

Conversation

jakewins
Copy link
Contributor

This builds on the TLS PR, please don't merge this before the TLS PR.

See the last commit for details of that this is.

This was a bit tricky, several things play into making this as
complicated as it turned out:

- TOFU (Trust on First Use) as we implement it only works on NodeJS,
  and only since nodejs/node@345c40b6
- Browsers do not support specifying which certificates to trust,
  so CA list configuration only works on NodeJS
- The location of `.neo4j/known_hosts`, used by TOFU, differs between windows
  and linux.

However, tests are now green, all rejoice. For a modern NodeJS
deployment, the driver now defaults to using encryption and uses TOFU
for establishing trust, meaning users will get a low-hassle encrypted
setup by default.

If users are running in a web browser, or running a several-years-old
version of NodeJS, the driver will default to not using encryption.
I'm not entirely comfortable with this, but doing encrypted websockets
in the browser is a massive hurdle for users, since each Neo4j database
has it's own self-signed certificate by default. It seems that if we
forced first-time users to install new CA certificates in their
browsers, they will just opt to turn encryption off.
Main point here is to add a small layer of indirection for accessing
fields in a record. Before this, we gave users a raw array instance
which is useful - but also means we can *never* add additional
functionality to a record, since we use up the "root" attribute space
with fields. Adding any additional attribute to the record would break
backwards compatibility.

This introduces a really frustrating wart in the API, where most other
access by key is done via JS object lookups (eg.
node.properties['blah']). However, records have both indexed and keyed
fields, meaning if a user ever did:

    RETURN 1, 0

It's now insane to figure out which value you get back when you ask for
record[0]. With this implemntation, there's a strict separation between
lookup by index (using JS number values) and lookup by key (using
String):

    get(0) -> 1
    get("0") -> 0

It also allows, as noted above, future extensions to the API, which the
original design made very cumbersome.
@jakewins
Copy link
Contributor Author

Reviewed by @oskarhane

jakewins added a commit that referenced this pull request Mar 18, 2016
@jakewins jakewins merged commit 3a432ca into 1.0 Mar 18, 2016
@jakewins jakewins deleted the 1.0-record branch March 18, 2016 03:08
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.

1 participant