Hi Timo, You are right. The phrasing from the examples page is not completely accurate. While there seem to be two distinct API. In fact, the implementation is the same, and the DSL API invokes methods from the regular one to build queries. There are two reasons for this separation:
1. For historic reasons: the "regular API" was there first. I added the DSL API later. In the beginning, I didn't even think of the fact, that I could include a DSL in my tool 2. For practical reasons: the "regular API" is might be better to use, when a "builder pattern" needs to be applied, as you put it. I know of many cases, where SQL construction is done most easily by passing an SQL statement object around and adding to it. The DSL imposes a rather strict order of clause additions, and that can be bad at some times. Cheers Lukas 2011/1/4 timowest <[email protected]> > I found the following comparison on your Examples page : > > Use the DSL API when: > * You want your code to look like SQL > * You want your IDE to help you with auto-completion (you will not > be able to write select .. order by .. where .. join or any of that > stuff) > > Use the regular API when: > * You want to create your query step-by-step, creating query parts > one-by-one > * You need to assemble your query from various places, passing the > query around, adding new conditions and joins on the way > > Why do you restrict the DSL API to a builder approach? It could easily > work also in incremental fashion. > > The separation adds some unnecessary complexity. > > I am just throwing some suggestions, because I have come across > similar design decisions.
