Document db.create.setRelationshipVectorProperty procedure

[renetapopova]

No description provided.

[parnmatt]

ANY is a limitation of the procedure framework, and how it currently works to try and automatically figure out the type … which is only used for that test against the JSON file.

It's real signature would be LIST<INTEGER | FLOAT>.

Suggested change

	m| db.create.setRelationshipVectorProperty(relationship :: RELATIONSHIP, key :: STRING, vector :: ANY)
	m| db.create.setRelationshipVectorProperty(relationship :: RELATIONSHIP, key :: STRING, vector :: LIST<INTEGER | FLOAT>)

and now same above for setNodeVectorProperty, (and setVectorProperty
I'm just confirming with @nilsceberg if it is an additive change, or technically always was that and thus a correction to the docs.

[parnmatt]

Nils has just confirmed with 5.16 that it worked with a LIST<INTEGER>; therefore, updating setNodeVectorProperty and setVectorProperty to LIST<INTEGER | FLOAT> is a docs correction and shouldn't required noting it as a signature change.

[renetapopova]

Hmm, this is from the codebase.

[parnmatt]

Indeed, I believe you're specifically referring to procedures.json, which is only used in procedure and function acceptance tests from cypher ops. I guess docs use this for reference too in that case?

---

For reference and clarity,
The procedure framework unfortunately sees almost anything that uses one of our internal types as ANY.
Even if it was a FloatingPointArray which is LIST<FLOAT>, it would be ANY in that type detection.

Semantically, and through enforcement of manual type checking, it should be LIST<INTEGER | FLOAT> here.
We are using the internal types for performance reasons, and this is an implementation detail.

If we were writing this in scala where some of their procedures/functions are, I believe the signature checker would use the static one that is provided, and thus correctly pick up it was a LIST<INTEGER | FLOAT> but I could be wrong.

Either way, the ANY in that JSON file are to satisfy those tests.

[renetapopova]

Yes, we use the Cypher command SHOW PROCEDURES to validate the available procedures, their description, signature, and mode. I can see that the genai.vector.encodeBatch is missing in the json now. What happened to it?

[renetapopova]

Going back from ANY to LIST<INTEGER | FLOAT> in the documentation (if we are able to that in the future) seems like more of a breaking change than treating the SHOW PROCEDURES output as a bug. :S

So, are you suggesting to ignore the tests and just add LIST<INTEGER | FLOAT> instead of ANY even though the users will see a different signature when they run SHOW PROCEDURES?

[nilsceberg]

I think we should at least consider that, yes. Perhaps we could note the discrepancy in the docs?

[renetapopova]

I am not sure what we should do in such cases. The documentation reflects what's in the output of SHOW PROCEDURES because that's what users see. If the output shows ANY, the docs also show ANY. And as per the docs test, everything seems fine.

[nilsceberg]

And as per the docs test, everything seems fine.

Wait, are the tests passing for e.g. queryNodes? It currently seems to say query :: LIST<FLOAT> in the docs but that has also recently changed to ANY in the SHOW PROCEDURES output, unless I'm mistaken 🤔

[renetapopova]

I think we should at least consider that, yes. Perhaps we could note the discrepancy in the docs?

What would be a good note for that? Could you provide us with some content?

[parnmatt]

Should we also document db.index.vector.queryRelationships here as well, or would it be best to do so in another PR?
(thus also db.index.vector.queryNodes with LIST<FLOAT> to LIST<INTEGER | FLOAT>)

[neo-technology-commit-status-publisher]

Thanks for the documentation updates.

The preview documentation has now been torn down - reopening this PR will republish it.