Thanks Lukas, that's very helpful.
Regarding the immutability: I am currently doing it the way you propose,
using the return value. However, could that still be a problem, e.g.
b = a.join(x)...
c = b.where(y)
b(?).join() ? - will this not work, assuming immutability enforcement
applies across clauses, not just within them?
Since it's probably premature for me to future-proof things now, and since
I think using the DSL is the "nicest" way, I'll try to keep using that
where possible. The table.join() approach looks good too, I'll keep that in
mind as an alternative (though it could mean some code rearranging).
Just curious, is there a strong reason to add the immutability you
described?
Thanks again,
Dan
On Friday, July 12, 2013 5:54:42 PM UTC+10, Lukas Eder wrote:
>
> 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] <javascript:>>
>
>> 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] <javascript:>.
>> 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.
