-
Notifications
You must be signed in to change notification settings - Fork 29
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
[hZww9vSJ] Make the type output of apoc.schema.* procedures more specific #307
Conversation
98e794d
to
3307ed5
Compare
4e1c078
to
4f0fc6a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks really good :) Can you please update the docs as well to show the correct type (i.e not uniqueness), just one small comment otherwise! Nice :D
I also agree this isn't breaking as it is a bug fix!
result -> { | ||
while (result.hasNext()) { | ||
Map<String, Object> r = result.next(); | ||
System.out.println("r = " + r); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably best to remove print statements now :)
@gem-neo4j I added the docs pr: https://github.com/neo4j/docs-apoc/pull/107 |
Great, I'll review the docs when I have time, thanks! :D |
…ific (neo4j/apoc#307) * [hZww9vSJ] Make the type output of apoc.schema.* procedures more specific * [hZww9vSJ] Fix some SchemasEnterpriseFeaturesTest * [hZww9vSJ] Remove println
…ific (neo4j/apoc#307) (neo4j/docs-apoc#107) (#3635) * [hZww9vSJ] Make the type output of apoc.schema.* procedures more specific (neo4j/apoc#307) * [hZww9vSJ] Make the type output of apoc.schema.* procedures more specific * [hZww9vSJ] Fix some SchemasEnterpriseFeaturesTest * [hZww9vSJ] Remove println * [hZww9vSJ] Make the type output of apoc.schema.* procedures more specific (neo4j/docs-apoc#107) * [hZww9vSJ] Make the type output of apoc.schema.* procedures more specific * [hZww9vSJ] var. output description changes, moved config, added tables * [hZww9vSJ] improved populationProgress description * [hZww9vSJ] small changes * [hZww9vSJ] cypher style and some small changes - changed note for exclude/include config * [hZww9vSJ] small change * [hZww9vSJ] removed unused imports
Changed
ConstraintDescriptor
toConstraintDefinition
innodeInfoFromConstraintDefinition
.This to be consistent with
relationshipInfoFromConstraintDefinition
and to retrieve the constraint type withconstraintDefinition.getConstraintType().name()
, easier to implement and not internal.The only con is that to get the "userDescriptor" output I have to use this method
ktx.schemaRead().constraintGetForName(constraintDefinition.getName()).userDescription(tokens)
.Alternatively, I could remain ConstraintDescriptor and derive the type of constraint via a method like this, but it's not future-proof:
With this implementation, a uniqueness constraint returns 2 results (1 index "RANGE" and a constraint "UNIQUENESS"), consistently to relationships (previously returned a generic "INDEX" result).
I don't think it's a breaking-change but rather a bug as the documentation says
returns ALL indexes and constraints information for all node labels in the database.
.If in doubt, I can create a card and maybe discuss it together.
indexDescriptor.isUnique() ? "UNIQUENESS" : "INDEX";
toindexDescriptor.getIndexType().name();
"INDEX"
fromtype
outputSchemas.relationshipInfoFromIndexDescription