-
Notifications
You must be signed in to change notification settings - Fork 1
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
Allow customised package names in Cypher type system #4
Comments
A possible problem with this approach is that the client’s type package would use the exact same data structure as the Neo4j::Driver type package does. This might violate encapsulation and result in more brittle code. To combat this, Neo4j::Driver should document that direct data structure access is unsupported, even from the client’s package. Instead, clients should inherit from the Neo4j::Driver type package using package REST::Neo4p::Node;
# Bad example
sub add_labels {
my $id = shift->{_meta}->{id}; # Don't do this!
...
}
# Good example
our @ISA = qw( Neo4j::Driver::Type::Node );
sub add_labels {
my $id = shift->id();
...
} Additionally, Neo4j::Driver should provide at least one hash key for safe internal use by the client. For example, Neo4j::Driver documentation could guarantee to never use hash keys beginning with |
Initial implementation landed, see "Type system customisation" in Neo4j::Driver 0.14. Would @majensen consider this suitable for adapting REST::Neo4p to use Neo4j::Driver? Are any other changes to Neo4j::Driver necessary (or perhaps just useful)? |
Will have a go at this |
Great! Just let me know what you need. |
With REST::Neo4p 0.4000 released, I guess this can be closed. But I like the flexibility this option provides, and am leaning towards eventually making it a stable feature. |
The package names that this driver’s Cypher type system uses to
bless
objects like Neo4j nodes and Neo4j relationships returned from executed queries should be customisable. This would support clients adding their own methods to such objects. See majensen/rest-neo4p#20 (comment) for an example of how this might work.API usage might look like this:
The client’s type package could implement any methods that it likes. For example,
REST::Neo4p::Node
might wish to offer methods such asnew()
oradd_labels()
, whichNeo4j::Driver::Type::Node
doesn’t have.The text was updated successfully, but these errors were encountered: