Great, thanks. I'll make further comments there to avoid spamming this list.
On Wed, Sep 25, 2013 at 12:06 AM, Lukas Eder <[email protected]> wrote: > > 2013/9/21 Daniel Danilatos <[email protected]> > >> On Sat, Sep 21, 2013 at 12:20 PM, Lukas Eder <[email protected]>wrote: >> >>> >>>>> Nonetheless, I think that supporting "inheritance" modelled as a set >>>>> of 1:1 relationships with some sort of discriminator might be a good thing >>>>> to implement in jOOQ. Obviously, such an implementation should be somewhat >>>>> compatible with JPA, to follow the principle of least astonishment. >>>>> >>>> >>>> If jOOQ provides the right set of primitives, there should be no need >>>> to bake in this feature, as it would be easily implementable on top. I >>>> know I'm oversimplifying, and I don't have all the hundreds of use cases in >>>> mind that you need to juggle, but as a simple example: say the generated >>>> record classes did not fit into a large inheritance hierarchy, but instead >>>> subclassed a very simple delegating base class (merely to take care of most >>>> of the boilerplate) and then were implemented by receiving an inner record >>>> in their constructor. The actual code would be very similar - the setFoo >>>> and getBar methods would still delegate to setValue & getValue, except on >>>> an inner object, instead of their parent class. Except now I can provide >>>> any other backing record of my choosing in the constructor, and reuse all >>>> this conveniently generated code. For example, I can pass in a record that >>>> is the result of a join query, to get a certain view of it, read values >>>> with nice getters, make changes with nice setters, etc. >>>> >>> >>> Aha, I see what you mean. Interesting. Let me challenge that :-) >>> >>> jOOQ doesn't rely on any setters or getters, such as setFoo() or >>> getBar(). jOOQ will map values through Field<?> references in setValue() >>> and getValue(). The reason is simple: Many queries performed with jOOQ are >>> not queries against a single table, where the resulting record has >>> well-defined setters and getters. Most queries will produce "ad-hoc", >>> generic records. But this is feasible, of course. The simple delegating >>> base class that you mentioned would allow for overriding setValue() and >>> getValue() behaviour. >>> >>> It would also need to allow for overriding the changed() behaviour, as >>> tracking jOOQ's internal "changed" flag would need to be delegated as well. >>> >>> Now, I don't know if overriding the behaviour of single set/get methods >>> is good enough. If you want to perform sophisticated record <-> domain >>> mapping algorithms, you might want to combine two database values into one >>> domain object. For instance (FROM_DATE, TO_DATE) <-> MyObject.DateRange. >>> But maybe, that's feasible through only set/get. >>> >>> But generally, I feel that such a model solves only few problems while >>> adding a lot of complexity to the already very complex >>> org.jooq.UpdatableRecord type... >>> >> >> What I'm proposing hopefully shouldn't add any complexity (I'm really >> just advocating composition over inheritance) - basically saying >> (approximately) whatever you do now that delegates to an abstract base >> class, delegate to a wrapped record. It may even reduce complexity, and it >> will allow more combinations of possibilities hence more flexibility (as a >> minimum I could implement the fancy features described above, but I predict >> there is much more). >> >> Of course I don't want to come across as suggesting you go and refactor >> everything... just throwing out an idea, and one that could potentially be >> done incrementally (though that would by definition add complexity because >> you'd have two ways of doing things, if you purely added facilities for >> composition without removing much of the inheritance). >> >> For the record I solved my problem at the application level using a >> high-level wrapper class, which ended up OK, but it means the application >> code has two ways of doing things depending on whether or not I'm dealing >> with these joined records via a wrapper, or directly with regular records. >> > > I think it's hard to assess how complex support for view records would be > without going through the exercise of actually trying to implement it. > #2721 has already been registered, hopefully for jOOQ 3.3.0, which will > certainly be released in 2013: > https://github.com/jOOQ/jOOQ/issues/2721 > > Anyway, no matter if I will come to the conclusion that this is a valuable > addition in terms of cost/effect ratio, it's certainly a very interesting > idea! > > 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. > -- 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.
