Refactor TCK compability proposal

[otaviojava]

Hey @njr-11 , I’m aligned with your proposal, especially the idea of clarifying this in the vendor documentation.

That said, I think we should go one step further and make the capabilities themselves more explicit, including stronger documentation around what each one actually means.

For example, capableOfNull it can be misleading. NoSQL databases may handle null, but not necessarily in the same way as a relational database. The behavior may vary depending on whether the database is schema-based or schemaless.

The same applies to count. Supporting count does not always mean supporting count in every context, such as pagination or conditional queries. A database may support counting the total number of records, or counting only by key or id access, while still not supporting count with broader restrictions.

Because of that, I would suggest using polymorphism. It would let us make the behavior more explicit and improve the documentation incrementally, class by class.

PS: for now, I have not changed the behavior itself. I only proposed the interfaces and structure, this change would become much bigger.

If you agree, we can go deeper and review the interfaces and implementations one by one, using the spec as the reference.

[njr-11]

This works, but it is also a lot more complex. The information is no longer centralized and is spread throughout various classes. The main benefit I can see is if we believe there will be a lot of scenarios where the ordering KEY-VALUE < COLUMN < DOCUMENT < GRAPH < RELATIONAL will not apply. That is still possible with the existing approach but would require a switch statement and Otavio's proposal here would avoid that. What do others think? Either approach will work, but which is preferred?

[otaviojava]

Yep, we will include more complexity, but we can include more databases in these capabilities.

We have a timeseries and a vector database.

The problem, as you said, is more classes and also the work on documentation.

[KyleAure]

@otaviojava -- I agree with Nathan that this introduces a lot of boilerplate which can be hard to understand/navigate. Perhaps we could condense this logic down to a single record:

public record DatabaseCapability ( 
    boolean capableOfAddition,
    boolean capableOfAnd,
    boolean capableOfAssignmentToExpression,
    boolean capableOfBetween,
    boolean capableOfAttributeVsAttributeComparison,
    boolean capableOfConcat,
    boolean capableOfConditionalDelete,
    boolean capableOfConditionalUpdate,
    boolean capableOfConstraintsOnNonIdAttributes,
    boolean capableOfCount,
    boolean capableOfCountingDeletes,
    boolean capableOfCountingUpdates,
    boolean capableOfDivision,
    boolean capableOfGreaterThan,
    boolean capableOfGreaterThanEqual,
    boolean capableOfIn,
    boolean capableOfLeft,
    boolean capableOfLength,
    boolean capableOfLessThan,
    boolean capableOfLessThanEqual,
    boolean capableOfLike,
    boolean capableOfLower,
    boolean capableOfMultipleSort,
    boolean capableOfMultiplication,
    boolean capableOfNotBetween,
    boolean capableOfNotEqual,
    boolean capableOfNotIn,
    boolean capableOfNotLike,
    boolean capableOfNotNull,
    boolean capableOfNull,
    boolean capableOfOr,
    boolean capableOfParentheses,
    boolean capableOfQueryWithoutWhere,
    boolean capableOfRight,
    boolean capableOfSingleSort,
    boolean capableOfSubtraction,
    boolean capableOfUpper) {
    
    public static final DatabaseCapability minimalDatabaseCapability = new DatabaseCapability(false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false);
     
    // TODO add the rest
}

Just a thought.