-
Notifications
You must be signed in to change notification settings - Fork 0
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
Don't implement property-container #1
Comments
* Created a new interface called DetachedPropertyContainer that is similar to PropertyContainer but decouples from the neo4j embedded database (e.g. no GraphDatabaseService). #1 * Fixed a test case that depended on the order of a Set.
Thanks Michael. I just pushed a branch that replaces the PropertyContainer interface with a new DetachedPropertyContainer interface. The new interface has no reference to the GraphDatabaseService. Let me know if this is closer to what you had in mind. |
So you can actually remove the neo4j dependency? I mean labels don't have to be exposed remotely. Just a string is good enough. |
I get what you're saying now. No need to bind this to the embedded API at all. |
It' a broken abstraction over the wire. And it binds your library to neo4j-embedded which it shouldn't be.
Use a cleaner implementation if you really want to support nodes and relationships. But mostly you'll be fine using maps for both. After all the metadata is not returned from the tx-endpoint. And the old "REST" representation shouldn't be used anyway as it is super wasteful.
The text was updated successfully, but these errors were encountered: