Better introspection for QBSelect and associated types

Discuss all feature requests you have for a new Servoy versions here. Make sure to be clear about what you want, provide an example and indicate how important the feature is for you

Better introspection for QBSelect and associated types

Postby jgarfield » Wed Dec 11, 2013 6:46 pm

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
Programmer.
adBlocks
http://www.adblocks.com
jgarfield
 
Posts: 223
Joined: Wed Sep 28, 2005 9:02 pm
Location: Boston, US

Re: Better introspection for QBSelect and associated types

Postby rgansevles » Mon Dec 16, 2013 11:14 am

James,

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.

Rob
Rob Gansevles
Servoy
User avatar
rgansevles
 
Posts: 1927
Joined: Wed Nov 15, 2006 6:17 pm
Location: Amersfoort, NL

Re: Better introspection for QBSelect and associated types

Postby jgarfield » Mon Dec 16, 2013 6:52 pm

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.
Programmer.
adBlocks
http://www.adblocks.com
jgarfield
 
Posts: 223
Joined: Wed Sep 28, 2005 9:02 pm
Location: Boston, US


Return to Discuss Feature Requests

Who is online

Users browsing this forum: No registered users and 7 guests