The QBSelect set of tools, and their fluent style, are fantastic for producing queries when you are composing an entire query all at once.
One the other hand, when you need to build up a query over time and not all conditions are known at the start, the tools become somewhat less useful.
What is largely lacking is the ability to introspect on the various components of a given query. This makes it more difficult to both dynamically build up a query based on its components, and to properly unit test any functions that return a QB object.
In some ways it seems that QBSelect has been designed to free the developer from needing to do checks such as "Have I already added this join? If not, add it now" by allowing the developer to add the same join twice, and the QBSelect will detect this and not allow a duplicate. Unfortunately, this is not the only use for that kind of introspection, e.g. "If I have added a join to table X, add condition Y, if not, add condition Z"
A small (non-comprehensive) list of useful additions would be
* QBSelect.getDataSource()
* QBJoin.getDataSource()
* QBJoin.getJoinType()
* Abilty to get and inspect entire list of joins, regardless of if they are named.
* QbSelect.getSQL (to get the final query that will be executed, this is more useful for debugging)
In general the idea is that if you have added information, you should at least be able to retrieve and inspect that information at a later point.
Cross-Post from (and voting at): https://support.servoy.com/browse/SVY-5620