Hi Dan
There are several ways to implement dynamic SQL in jOOQ:
1. Use the "model" API instead of the "DSL" API [1]
2. Factor out your table source and provide it only when constructing the
final query. See example below.
3. Use the approach you're using, keeping references to intermediary query
construction steps
You can choose the way you prefer, they're all valid. jOOQ follows semantic
versioning [2]. So unless we're doing something terribly wrong, referencing
SelectJoinStep et al. won't cause issues in future minor releases. Do note,
however, that in a future major release 4.0, the Select DSL may switch from
being "mutable" to being "immutable". So it may be better to re-assign the
SelectJoinStep:
===================================================
// Do this:
SelectJoinStep s;
s = s.join(x).on(a);
s = s.join(y).on(b);
// instead of this:
s.join(x).on(a);
s.join(y).on(b);
===================================================
This is also documented in [1].
An example for 2) factoring out table sources:
===================================================
Table<Record> table = BASE_TABLE;
if (someCondition)
table = table.join(ANOTHER_TABLE).on("a = b");
if (someOtherCondition)
table = table.join(YET_ANOTHER_TABLE).on("c = d");
// and then
DSL.using(configuration)
.select(...)
.from(table)
.where(...)
===================================================
Note that SelectJoinStep is just a convenient way of creating a joined
table as specified in the SQL standards and by most databases. JOIN is not
really a SELECT clause.
Cheers
Lukas
[1]:
http://www.jooq.org/doc/3.1/manual/sql-building/sql-statements/dsl-and-non-dsl
[2]: http://semver.org
2013/7/12 Dan <[email protected]>
> Hi all,
>
> I've just started using JOOQ and am excited about it. I've hit a snag with
> something I'm trying to do, I can see a some ways around it but perhaps
> people on this list will point out the best way (or perhaps something
> obvious I'm missing).
>
> As I understand, when building a query, the returned type goes through
> various steps e.g. SelectJoinStep, SelectConditionStep. This is clearly
> beneficial in most cases. However, in my case, I want the query to be built
> up by different parts of the code - for example, one part will add certain
> joins, another part will add certain other constraints, which are part of a
> "configuration" stage, before finally giving it to the main part of the
> code that will then build and execute the rest of the query [1]. The
> problem is, if I've needed to add some constraints on the SelectConditionStep,
> I don't have the SelectJoinStep any more.
>
> Actually, if I simply retain a reference to the earlier Join step, I can
> still modify it, and that seems to work - is that luck, or can I rely on
> this now and into the future? A quick look at the code makes me think it's
> OK, but I didn't dig too deep. Is there a "best practice" for this kind of
> use case?
>
> Happy to write more if my use case isn't very clear.
>
> Thanks,
> Dan
>
> [1] The motivation is to factor out certain query filtering (say, date
> ranges, or content versions, etc) from the main logic of the feature doing
> the query, as what filtering applies can change depending on context
> orthogonal to the feature.
>
> --
> You received this message because you are subscribed to the Google Groups
> "jOOQ User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
