Thoughts and wishes for API v7

[andreloeffelmann]

Since the first alpha releases for API v7 are out, I want to share some thoughts on it.

• It seems like the new filter operators are coming. Great to hear that! I hope you have Add new filters for String types to enable case-insensitive filtering #4827 in mind? Would be a really nice feature to have string comparison ignoring case finally :)
• Remove single relationships #5819 removes single element relationships. I understand the intention behind that. However, as already discussed in several tickets, e.g. here, the :1 relationship is a BIG and important thing (a Product has ONE Price and is produced by ONE Company).
  Our API relies heavily on this feature. The release notes on v7 describe how to use the @cypher directive to achieve the removed behaviour. Since filtering on @cypher fields is possible, this seems to be working.
  But that's only for READ scenarios. How about WRITE? It is not sufficient to just READ nodes connect in a :1 manner. We also have to CREATE, UPDATE, DELETE them. Is this coming as a new feature as proposed by me in Extend the @cypher directive with statements for create/update/delete mutations to be able to mutate properties which are resolved by a @cypher directive #1962? Or how are you planning to workaround WRITE scenarios?

But overall we are excited and look forward to v7! Is there an approximate timeline as to when we can expect a final release??

[darrellwarde]

• It seems like the new filter operators are coming. Great to hear that! I hope you have Add new filters for String types to enable case-insensitive filtering #4827 in mind? Would be a really nice feature to have string comparison ignoring case finally :)

Definitely, this kind of feature request is one of the many reasons we are making this change to the input types! We may not add it directly in 7.0.0, but it can certainly be expected not far behind.

• Remove single relationships #5819 removes single element relationships. I understand the intention behind that. However, as already discussed in several tickets, e.g. here, the :1 relationship is a BIG and important thing (a Product has ONE Price and is produced by ONE Company).
  Our API relies heavily on this feature. The release notes on v7 describe how to use the @cypher directive to achieve the removed behaviour. Since filtering on @cypher fields is possible, this seems to be working.
  But that's only for READ scenarios. How about WRITE? It is not sufficient to just READ nodes connect in a :1 manner. We also have to CREATE, UPDATE, DELETE them. Is this coming as a new feature as proposed by me in Extend the @cypher directive with statements for create/update/delete mutations to be able to mutate properties which are resolved by a @cypher directive #1962? Or how are you planning to workaround WRITE scenarios?

I think the important thing to note here is that we are removing this functionality because we simply cannot guarantee the adherence to any particular relationship cardinality. The long term answer to this problem is constraints in the database to control this, but this will be a long long way off. In the interim, I'm afraid that the answer may be more around workarounds. For example, having a Cypher field to read the data, which contains the logic of how to decide which node to return. And then mapping a relationship field which is write-only and using this for the modification of data, just without any guarantees of cardinality. We'll look to do a write up of a workaround such as this because I agree that it's perhaps not intuitive.

But overall we are excited and look forward to v7! Is there an approximate timeline as to when we can expect a final release??

We are aiming for around the end of March/beginning of April. 🙂