Inline On Fri, Dec 23, 2016 at 11:11 AM, Lukas Eder <[email protected]> wrote:
> Hi Samir, > > Thanks for your quick feedback. I'm happy to hear that you're getting > value out of this release already :) > > I will comment inline. > > 2016-12-23 17:46 GMT+01:00 Samir Faci <[email protected]>: > >> 1. JSR-308 looks great. I turned that on right away. >> > > Excellent > > >> 2. I'm not sure this is a 3.9 feature but I flipped fluentSetters on. >> It's nice pattern that can be handy at times. >> > > Nope, that's been around for a while: > https://github.com/jOOQ/jOOQ/issues/674 > > >> 3. I really like the fact that JavaTimeTypes have been added though it >> is a breaking change if you turn it on since all our previous >> generated was using java.sql.timestamp instead. >> > > Yes, there's no other way. But we made the flag inactive by default, so > the breaking change is an opt-in change. > > >> I am curious what other work is left regarding this date/time type >> regarding timezone support that was hinted on in the release announcement. >> > > There's still quite a bit of work here. In principle, those data types are > supported, but there are issues in many databases. We'll fix those issues > in the next months as 3.9.x patch releases. > > It would be nice if you could specify a white list of tables / schemas to >> apply the change to. I'm guessing this can be done via a custom >> generator. Though it'd be nice to have a pattern where we can white list >> or exclude tables from taking advantage of a particular feature. >> >> <pojos.include> .... </pojos.include> >> <JavaTimeTypes.include> .... </JavaTimeTypes.include> >> >> OR >> >> <pojos.include> .... </pojos.include> >> <JavaTimeTypes.include> .... </JavaTimeTypes.include> >> >> >> for example. >> > > In my opinion, that's overkill. JDBC has two types representing the same > thing as well: > > Timestamp = LocalDateTime > Time = LocalTime > Date = LocalDate > ? = OffsetDateTime > ? = OffsetTime > > So, jOOQ also implements this duality, and you should either choose one > side or the other side. > > If there's really a compelling reason to have a 50:50 distribution of > "old" vs. "new" temporal types in generated code, users can still use > <forcedType/> and convert manually. > I'll look into the forcedType, and yes you're probably right about it being overkill. It's really just a bandaid that would be needed to help transition over. Once that's done it would be throw away code. > From our side the only featureI can think of that'd be real nice to have >> is the insertInto(Table).set(....).onConflict(....).doUpdate().retu >> rning(Field[]). >> >> I believe there's an issue <https://github.com/jOOQ/jOOQ/pull/5493> >> already open slated for 3.10.0. >> > > Yes, that's it > > Thanks, > Lukas > > -- > 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/d/optout. > -- Thank you Samir Faci https://keybase.io/csgeek -- 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/d/optout.
