Update the spec to fix the issue 782

[otaviojava]

This PR has the goal of fixing some points that we find on the TCK review:

• TCK cannot require GT, GTE, LT, LTE for Key-Value databases #779
• TCK cannot require Contains, EndsWith, IgnoreCase, Like, Null, StartsWith for Document and Graph, TCK cannot require Between, True, False for Key-Value #783
• limitations on sorting and In, Or, And keywords #794
• Document databases might not be capable of parentheses

There are three more to fix. However, those will go using Javadoc. Thus, I will create as we finish and solve this one.

Ref: #782

[otaviojava]

@njr-11, when you have time, could you review this one, please?

[njr-11]

To start out with, I reviewed the first two sections adding some suggestions for making the making the requirements more clear of what must be supported vs what is not required. I don't have expertise in these NoSQL databases, so I might have gotten some of the clarifications incorrect. I tried to use what the TCK is enforcing in the referenced issues as a guide, as well as the proposed text that was here.

I'll follow this up with reviewing the other sections but wanted to save this before an error occurs and I need to start over.

[otaviojava]

It happens in the majority of NoSQL databases of wide-column, but not all.

Those are samples, that is the reason we don't make it mandatory, I can assume to the majority, but not for all

NoSQL Database	Supports AND Operator
Apache Cassandra	✅ Yes
Apache HBase	❌ No
ScyllaDB	✅ Yes
Google Bigtable	❌ No
Amazon Keyspaces	✅ Yes
Hypertable	❌ No
Azure Cosmos DB (Cassandra API)	✅ Yes

[njr-11]

That's good information. I think the TCK might need to be updated because it only makes the allowance to not support for Key-Value, not Column,

        try {
            AsciiCharacter del = characters.findByIsControlTrueAndNumericValueBetween(33, 127);
            assertEquals(127, del.getNumericValue());
            assertEquals("7f", del.getHexadecimal());
            assertEquals(true, del.isControl());
        } catch (UnsupportedOperationException x) {
            if (type.isKeywordSupportAtOrBelow(DatabaseType.KEY_VALUE)) {
                // Key-Value databases might not be capable of And.

[otaviojava]

@njr-11, what do you want to do?

A) Finish those topicinat the documentation and then go to fix the TCK
B) Open a PR in parallel to fix it simultaneously.

[njr-11]

@njr-11, what do you want to do?

A) Finish those topicinat the documentation and then go to fix the TCK
B) Open a PR in parallel to fix it simultaneously.

It is completely fine to use separate PRs to split out work such as updating errors that we spot in the TCK while working on this. There is another minor error that I noticed as well. I'll get a PR (#946) open for that and we can continue on with the documentation accordingly.

[otaviojava]

Thanks, it does make sense. I reviewed and moved it.

[otaviojava]

To start out with, I reviewed the first two sections adding some suggestions for making the making the requirements more clear of what must be supported vs what is not required. I don't have expertise in these NoSQL databases, so I might have gotten some of the clarifications incorrect. I tried to use what the TCK is enforcing in the referenced issues as a guide, as well as the proposed text that was here.

I'll follow this up with reviewing the other sections but wanted to save this before an error occurs and I need to start over.

Thanks, @njr-11 , NoSQL can help with that. I accepted your points, plus I give you some context.

[njr-11]

Some more comments. Still need to cover the last 2 sections.

[njr-11]

I made it through reviewing the remaining sections. I'm still unsure what to suggest for Document and Graph Databases with respect to arithmetic operations and parentheses, having noted that the TCK seems to have requirements for Graph.

[njr-11]

That's good information. I think the TCK might need to be updated because it only makes the allowance to not support for Key-Value, not Column,

        try {
            AsciiCharacter del = characters.findByIsControlTrueAndNumericValueBetween(33, 127);
            assertEquals(127, del.getNumericValue());
            assertEquals("7f", del.getHexadecimal());
            assertEquals(true, del.isControl());
        } catch (UnsupportedOperationException x) {
            if (type.isKeywordSupportAtOrBelow(DatabaseType.KEY_VALUE)) {
                // Key-Value databases might not be capable of And.

[njr-11]

Yeah, I can see why implementing count in Java would be a poor choice. I think the concern here will be whether any of this is a breaking change because we are lifting a requirement for it to work - if anyone was relying on it already, it will break if taken away, but that might as much an issue from the Jakarta Data provider as the spec itself.

[njr-11]

I proposed some updates to align with what I think was the outcome of the discussion on parentheses for Graph databases, if I understood correctly.

[otaviojava]

I proposed some updates to align with what I think was the outcome of the discussion on parentheses for Graph databases, if I understood correctly.

Thanks, I've modified this one. Please check.

[njr-11]

Thanks for getting all of this detail written into the spec!

[otaviojava]

Thanks for getting all of this detail written into the spec!

Thank you for all the support. It is not done yet, but I will create a new PR. This one is already big enough.