Skip to content
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

[Zl3h9sM8] apoc.schema.relationships return wrong output for relationship indexes #247

Merged
merged 3 commits into from
Nov 24, 2022
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -9,16 +9,19 @@ public class IndexConstraintRelationshipInfo {

public final String name;

public final Object type;
public final String type;

public final List<String> properties;

public final String status;

public final Object relationshipType;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this an Object? (I see it was before as well), but is it not just a string?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Because relationshipType can also be a List<String>, in case of composite indexes, e.g. in testIndexesWithMultipleLabelsAndRelTypes https://github.com/neo4j/apoc/pull/247/files/9b4b7bf4448cf27d6daff1f1bc9a9d44e23aa11e#diff-231d1cab850aaf45247b0fd9e1a64e18a8002685841df498e2098c38bedf6fb3R758

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah makes sense, thanks :)


public IndexConstraintRelationshipInfo(String name, Object type, List<String> properties, String status) {
public IndexConstraintRelationshipInfo(String name, String type, List<String> properties, String status, Object relationshipType) {
Copy link
Contributor

Choose a reason for hiding this comment

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

can we call this constraintType then it is even less confusing, if you agree, change the one in Nodes as well :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, changing the name is a good idea, but maybe I would change the name to schemaType,
because constraintType = INDEX is personally confusing anyway.

It would seem clearer to me even if this change will be made: #247 (review)

Copy link
Contributor

Choose a reason for hiding this comment

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

ah fair enough, schemaType works better :) just internally anyway

this.name = name;
this.type = type;
this.properties = properties;
this.status = status;
this.relationshipType = relationshipType;
}
}
10 changes: 6 additions & 4 deletions core/src/main/java/apoc/schema/Schemas.java
Original file line number Diff line number Diff line change
Expand Up @@ -574,14 +574,15 @@ private IndexConstraintRelationshipInfo relationshipInfoFromIndexDescription(Ind
.mapToObj(tokens::propertyKeyGetName)
.collect(Collectors.toList());
try {
return new IndexConstraintRelationshipInfo(getSchemaInfoName(relName, properties), relName, properties, schemaRead.indexGetState(indexDescriptor).toString());
return new IndexConstraintRelationshipInfo(getSchemaInfoName(relName, properties), "INDEX", properties, schemaRead.indexGetState(indexDescriptor).toString(), relName);
} catch (IndexNotFoundKernelException e) {
return new IndexConstraintRelationshipInfo(
// Pretty print for index name
getSchemaInfoName(relName, properties),
relName,
"INDEX",
Copy link
Contributor

Choose a reason for hiding this comment

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

above we check: !indexDescriptor.isUnique() ? "INDEX" : "UNIQUENESS", coming very soon is new relationship constraints that allow this, does this check work here too?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh you're right, I didn't remember about your card, I was referring to the current version. Updated :)

properties,
"NOT_FOUND"
"NOT_FOUND",
relName
);
}
}
Expand All @@ -597,7 +598,8 @@ private IndexConstraintRelationshipInfo relationshipInfoFromConstraintDefinition
String.format("CONSTRAINT %s", constraintDefinition.toString()),
constraintDefinition.getConstraintType().name(),
Iterables.asList(constraintDefinition.getPropertyKeys()),
""
"",
constraintDefinition.getRelationshipType().name()
);
}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -382,6 +382,7 @@ public void testSchemaRelationships() {
Map<String, Object> r = result.next();
assertEquals("CONSTRAINT FOR ()-[liked:LIKED]-() REQUIRE liked.day IS NOT NULL", r.get("name"));
assertEquals("RELATIONSHIP_PROPERTY_EXISTENCE", r.get("type"));
assertEquals("LIKED", r.get("relationshipType"));
assertEquals(asList("day"), r.get("properties"));
assertEquals(StringUtils.EMPTY, r.get("status"));
assertFalse(result.hasNext());
Expand All @@ -401,12 +402,13 @@ public void testSchemaNodeWithRelationshipsConstraintsAndViceVersa() {
tx.commit();
return null;
});
testResult(session, "CALL apoc.schema.relationships() YIELD name, type, properties, status " +
testResult(session, "CALL apoc.schema.relationships() YIELD name, type, properties, status, relationshipType " +
"WHERE type <> '<any-types>' " +
"RETURN *", (result) -> {
Map<String, Object> r = result.next();
assertEquals("CONSTRAINT FOR ()-[liked:LIKED]-() REQUIRE liked.day IS NOT NULL", r.get("name"));
assertEquals("RELATIONSHIP_PROPERTY_EXISTENCE", r.get("type"));
assertEquals("LIKED", r.get("relationshipType"));
assertEquals(asList("day"), r.get("properties"));
assertEquals(StringUtils.EMPTY, r.get("status"));
assertFalse(result.hasNext());
Expand Down
9 changes: 6 additions & 3 deletions core/src/test/java/apoc/schema/SchemasTest.java
Original file line number Diff line number Diff line change
Expand Up @@ -349,7 +349,8 @@ public void testRelIndex() {
testCall(db, "CALL apoc.schema.relationships()", row -> {
assertEquals(":KNOWS(id,since)", row.get("name"));
assertEquals("ONLINE", row.get("status"));
assertEquals("KNOWS", row.get("type"));
assertEquals("KNOWS", row.get("relationshipType"));
assertEquals("INDEX", row.get("type"));
assertEquals(List.of("id", "since"), row.get("properties"));
});
}
Expand Down Expand Up @@ -712,7 +713,8 @@ public void testLookupIndexes() {
testCall(db, "CALL apoc.schema.relationships()", (row) -> {
assertEquals(":" + TOKEN_REL_TYPE + "()", row.get("name"));
assertEquals("ONLINE", row.get("status"));
assertEquals(TOKEN_REL_TYPE, row.get("type"));
assertEquals("INDEX", row.get("type"));
assertEquals(TOKEN_REL_TYPE, row.get("relationshipType"));
assertTrue(((List)row.get("properties")).isEmpty());
});
}
Expand Down Expand Up @@ -753,8 +755,9 @@ public void testIndexesWithMultipleLabelsAndRelTypes() {
testCall(db, "CALL apoc.schema.relationships()", (r) -> {
assertEquals(":[TYPE_1, TYPE_2],(alpha,beta)", r.get("name"));
assertEquals("ONLINE", r.get("status"));
assertEquals(List.of("TYPE_1", "TYPE_2"), r.get("type"));
assertEquals(List.of("TYPE_1", "TYPE_2"), r.get("relationshipType"));
assertEquals(List.of("alpha", "beta"), r.get("properties"));
assertEquals("INDEX", r.get("type"));
});
}
}