2013/7/12 Dan <[email protected]>
> 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?
>
Currently, b.join(...) will add another JOIN clause to the last-added table
in the select statement. The API does not guarantee this, however. So when
the API turns more immutable in the next major release, it may well be that
you'll be missing your predicate y in the type returned by b.join(...), as
that type will no longer be the same object as b (or c).
> 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).
>
It will be the most future-proof approach, as Table.join() methods are
already "immutable". You'll always get a new org.jooq.impl.JoinTable object
back from these join() methods.
>
> Just curious, is there a strong reason to add the immutability you
> described?
>
Yes, predictability. A mutable DSL API is not very predictable. In
particular because other clauses are immutable by nature, e.g.
Condition c = a.and(b);
c will wrap a and b, instead of modifying a.
The current mutability is an implementation detail that has leaked into the
DSL, unfortunately. In jOOQ 4.0, there will be an immutable DSL API and
(possibly) a mutable model API. I'm not 100% sure if the model API is
really useful. It might actually be removed in favour of reducing
complexity in the library.
Cheers
Lukas
> 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<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, SelectCon**ditionStep. 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 jooq-user+...@**googlegroups.com.
>>>
>>> For more options, visit
>>> https://groups.google.com/**groups/opt_out<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.
>
>
>
--
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.
