FMWK-427 Qualifier builder API redesign

[agrgr]

• QualifierBuilder: replace binName, binType, ctx, key with path
• Add @Beta annotation to QualifierBuilder
• Refactoring

[roimenashe]

2 setPath's in a single QualifierBuilder?

[agrgr]

It was left after uncommenting, thanks.

[roimenashe]

Do we need this comment? if not let's remove

[roimenashe]

@agrgr So path replaces binName with optional context and nestedKey, but it uses the sindex unique DSL which we use only in Spring Data Aerospike, I'm not sure about that.

1. For me binName with context and nested key is more intuitive than a path with a DSL but that's personal, in most cases queries won't include CTX/nesting so path is less self explanatory than binName.
2. A new DSL which will be used in the new Client API design is in the works, check for DSLPath here, it makes more sense for me to align with the new Client API DSL instead of with our sindex unique DSL which will probably be replaced with a new DSL.

Btw, keeping both is also an option which we can consider, that's what the new Client API does, for example change .setPath() to something like .setDSLPath() and keep binName, CTX etc... as they are).

I might be wrong, we can get into more details privately, lets talk about it.

[agrgr]

we can get into more details privately, lets talk about it.

@roimenashe Yes, let's discuss. Don't see any issue with having path in most cases containing only binName, this is exactly the idea - to have one field that describes whole path to the needed element, and not to require from a user to figure out what is the last element separately, or what is the correct CTX between binName and the last element (exlusive), etc. Besides, we are adding CTX support in the upcoming release, and integrating it into the path seemes like an option not to introduce new setters.

Moreover, the changes allowed to clean up QualifierBuilder API, so instead of many setters there are fewer which simplifies the usage and removes all internal setters.
Speaking about new DSL - again, let's talk, I think we might add support for newer DSL in future, however, we already are using singular path elements DSL in the @Indexed annotations, so it is more like a reuse of the existing API.

[roimenashe]

same here