apoc icon indicating copy to clipboard operation
apoc copied to clipboard

apoc.meta.data() reports wrong property type information

Open neo-technology-build-agent opened this issue 3 years ago • 4 comments

Issue by moxious Thursday Oct 17, 2019 at 18:50 GMT Originally opened as https://github.com/neo4j-contrib/neo4j-apoc-procedures/issues/1319


Replication that worked for me:

create (:A { x: 1 }), (:A { x: 'Foo' });
create (:B { x: 'Foo' }), (:B { x: 'Foo' }), (:B { x: 1 });
CALL apoc.meta.data();

This setup is intentionally to confuse APOC. For both labels A and B, the property X is typed both string and long.

The APOC call:

Screen Shot 2019-10-17 at 2 48 47 PM

This procedure uses a sampling configuration as specified by the config parameters, which is a MetaConfig object. The sampling appears respected, but the property type information stored in the MetaResult class is "last type in wins".

I would say this behavior is incorrect. There are two possible correct behaviors:

  1. Return an array of different types the property could have, as observed in the sample ["Long", "String"]
  2. Perform some type-coercion, and always report "String" as a single property type, because it is the widest of all observed types.

Comment by moxious Thursday Oct 17, 2019 at 18:53 GMT


I found this because the issue is related to a PR in progress. In that PR APOC will have different stored procs that return the array of encountered types (fix suggestion 1) . https://github.com/neo4j-contrib/neo4j-apoc-procedures/pull/1318

Comment by jexp Tuesday Oct 29, 2019 at 12:13 GMT


for the type field I would probably coerce to string and add another field types that has the full list either single element or multi

Comment by jexp Tuesday Oct 29, 2019 at 12:14 GMT


Probably also need to adapt in apoc.meta.schema

One could also report a dynamic union type of all observed types. That would be closer to how Cypher thinks about it.

hvub avatar Dec 17 '24 20:12 hvub