Hello Olli, > We are building and easy to use browser page for our business users for > making queries to Teradata for extracting records. The list of columns that > can be used in conditions and select lists is limited to about 30 columns in > a few tables. The users should be able to use and / or -logic.
That's an interesting use-case. Does jOOQ work OK for you with the Teradata database? Officially, that database is not yet supported, but I could maybe increase the priority of that RDBMS integration: https://sourceforge.net/apps/trac/jooq/ticket/629 > For persisting these queries my idea was that we would serialize a > org.jooq.SimpleSelectQuery or org.jooq.SelectQuery as XML into Oracle. How do you plan to serialise those objects? With java.beans.XMLEncoder? Just a thought: While I try to keep the API as consistent and backwards-compatible between releases, this does not hold true at all for the implementation. You might run into compatibility issues when upgrading jOOQ in the future. Migration of your serialised XML might be non-trivial... Maybe, this feature request might be useful to you, i.e. jOOQ natively supporting XML serialisation / deserialisation of QueryPart objects: https://sourceforge.net/apps/trac/jooq/ticket/642 > When > the user wants to view or alter the query through the browser page we would > need to open up the conditions inside the JOOQ object. > [...] > I had tried with this > QueryPartInternal qi = q.internalAPI(QueryPartInternal.class); > and this (we would recreate the UI objects by 'rendering' the query) > <my own class> implements RenderContext > but did not get much further. This is one option. It's the only guarantee that you'll actually reach every QueryPart including nested conditions and every conditions' Field / value pairs. I am not planning to expose those internals in the public API for now, as that would make for many more API methods, which aren't part of the DSL, e.g. Condition.getSubConditions(), Condition.getSubConditionOperator(), etc... > We can of course store the UI selection steps in our own objects and > recreate the JOOQ query every time the query is actually executed. Just > wanted to know which would be the way to go. This option will allow for the most flexibility, as you have full control over your queries. Also, I'd expect the least compatibility issues with this solution. Cheers Lukas
