Hello Thomas,
Thomas Fischer wrote:
T E Schmitz <[EMAIL PROTECTED]> schrieb am 06.08.2004 17:53:35:
For backwards compatibility we would need to leave the existing methods as is. There are I guess two ways forward, either we generate a second set of methods that do left joins or we add an option to the generator to determine if the existing or a left join should be used (I think the latter might be the best option).
<code snippet>
I aggree with you that your suggestion is more "backwards compatible" than the generator option. However, in my opinion, the "standard" join for 99% of the cases will be a left join, so I would also prefer the generator option. If one really wants to have an inner join, one could emulate it via a Criteria object which restricts the FK column to "NOT NULL".
I agree - the left join is probably the standard option (that's why I was so keen on it ;-) ) and doubling up all join methods would make the templates a bit messy. As long as the user isn't restricted to one type of join - now that inner and outer joins are possible! - that's the way to go.
Note that this requires SqlEnum to be public!
Most of the SqlEnum constants are made available as public constants in the Criteria object (e.g. Criteria.LEFT_JOIN is a SqlEnum Object), so I do not see the reason why you had to make SqlEnum public ..... As one usually wants only one access point to avoid confusion, the SqlEnum is not public. In my opinion, this is a correct decision.
It certainly is cleaner if SqlEnum remains non-public. However, if you wanted to parameterize the join methods with Criteria.LEFT_JOIN, etc. then the parameter would have to be an SqlEnum and hence have to be public.
--
Regards/Gruß,
Tarlika Elisabeth Schmitz
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
