> one features that was especially usefull was that it
> auto-generates two classes per table:
>
> class FooRecord extends BaseFooRecord {
> // empty
> }
>
> class BaseFooRecords extends BaseRecordOrWhatever {
> // many, many functions
> }
It's possible but hard to do right.
The main issue is that it's easier in PHP or any dynamic language than in Java
or static languages. You need to be extra careful to make everything have a
useful type.
Also, it can conflict with business-driven subclassing.
There are many cases where it's useful to map classes and their subclasses to
the database; combining that with the above approach naively will give you
multiple inheritance. (It's possible to do non-naively, of course, but it will
require some very careful design, else it risks performance problems or the
exclusion of valid use cases.)
It's also easy to get things wrong, particularly if bytecode instrumentation
comes into play. I suspect the actual problem wasn't in the two-class design
but that this design brought out some horrid design flaws in the proxy classes
that Hibernate generates - design flaws that wouldn't matter for a
non-inheriting entity class but that turned really ugly for inheriting entity
classes. Still, I take that as a warning that splitting a class into superclass
and subclass needs a careful review of anything that does introspection or
bytecode generation.
> However, I think that it is important to make
> BaseFooRecords abstract and allow only
> instanciation of FooRecord.
+1
--
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.
