Joachim! Let's solve tomorrow's problems... tomorrow :-) 2013/8/20 Durchholz, Joachim <[email protected]>
> >> What's worrying me most is the use case where people > >> want to organize some of their entity classes as > >> superclass and subclass. > >> I.e. the application programmer wants > >> > >> class BarRecord extends FooRecord > >> > >> and can't make BarRecord a subclass of BaseBarRecord > >> anymore. > > > > I'm not sure if I follow. So far, no one wanted to mix > > entities Foo and Bar, or do they? :-) > > Not in this thread. > > For a silly example, InternationalAddress could be a subclass of > NationalAddress. > The ADDRESS table would be in an optional to-one relationship to > INTERNATIONAL_ADDRESS. > > For a more practical example, I had two variants of sales data, which > needed to be fed into the same sales forecast module. > Since Hibernate's proxy classes derive from the entity class, direct > inheritance wouldn't work. In the end, I wrote a common interface with half > a metric ton of member accessors. > That's a somewhat different use case because there was no JOIN, just two > tables with a large overlap of common columns. With a JOIN, it would have > been a full metric ton of delegation code. Rest assured that I will soon feature a blog post rant about mixing this type of entity inheritance with relational models, as this can indeed go very wrong. I'm not even sure if anyone ever successfully tried using PostgreSQL's (or CUBRID's) table inheritance feature, which is not explicitly supported by jOOQ yet: http://www.postgresql.org/docs/9.3/static/tutorial-inheritance.html But let's get back to the original use-case in this thread :-) Cheers 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/groups/opt_out.
