Hi Max, On Thu, Sep 12, 2019 at 4:20 PM Max Kremer <[email protected]> wrote:
> No specific reason other than we haven't really needed to. > > Yes, we write our own TableImpl subclasses by hand but there are only 3-4 > of them. Our application is mostly doing analytics and we rely on JOOQ as a > DSL for building queries (creating reusable chunks of SQL and combining > them, manipulating them etc...). So far JOOQ has been perfect for that. We > haven't had the requirement to do typical CRUD operations on > records/objects.... until now. > I looked at the UpdatableRecordImpl class but the internal docs say *"This > type is for JOOQ INTERNAL USE only. Do not reference directly"* > When upgrading to a new jOOQ version I would recommend that you do run the code generator and at least compare its output to your own hand-maintained classes. The TableImpl class has the same disclaimer in the Javadoc and both classes are also annotated as @Internal. But extending either of these classes (like the code generator does) is legitimate. But please note that, since these are internal classes, the API could break in backwards incompatible ways in a future minor release. This is not a problem if you are using the code generator, as its API remains backwards compatible and it will always generate classes matching TableImpl and UpdatableRecordImpl. Regards, Knut -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAFx%3DKgfBYjnSy-BO-aAYsCia_KeL2UYofEP2rqwQ7ShbtZYkZg%40mail.gmail.com.
