Page 1 of 1

Better introspection for QBSelect and associated types

PostPosted: Wed Dec 11, 2013 6:46 pm
by jgarfield
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):

Re: Better introspection for QBSelect and associated types

PostPosted: Mon Dec 16, 2013 11:14 am
by rgansevles

These things could be exposed to the javascript api.
I guess for completeness the list of condition names should be added as well.

Note that QbSelect.getSQL() would return a string that may refer to temporary tables generated for the execution of the query.
Creation/cleanup would not be in that sql so for anything else then debugging it should not be used.
Since the logic to compile a query for a specific db is only on the server this wouild add a rmi-call for the smart client.


Re: Better introspection for QBSelect and associated types

PostPosted: Mon Dec 16, 2013 6:52 pm
by jgarfield
Agreed. Things like the full list of Conditions, list of Sorts, etc, along with the ability to inspect their component parts would want to be there for completeness.

That's an interesting note about how getSQL would need to work. It certainly makes me more interested in seeing the output, but also seems a step more complicated than I originally thought it would be, so I can see that being an addition of secondary importance compared to the rest of the introspective capabilities.