For the Querydsl metamodel, interfaces would make many things easier. The inheritance hierarchy for Querydsl expression types is quite complex and a bit difficult to maintain.
This is easier for the Scala version of Querydsl where traits are used and multiple inheritance is directly possible. For the generated domain model of the Querydsl SQL module we will probably continue with beans. Br, Timo On Jul 6, 11:28 am, Lukas Eder <[email protected]> wrote: > Hi Timo, > > Thanks for your feedback. > > > The problem with interfaces is that they need to be managed. In a > > generic Bean populating environment they cannot be instantiated. > > There will always be "beans" backing the interfaces. These ideas > haven't been worked out in detail yet, but I'd imagine there will be > plenty of factory methods allowing for accessing backing beans. For > instance, Creating a new record is simple: > > <R extends Record> R Factory.newRecord(Table<R> table); > > With the T_TREE example this would translate to a call similar to this one: > > TTreeRecord record = create.newRecord(TTree.T_TREE); > > This factory method is already available in jOOQ today. So the move > from beans to interfaces is backwards-compatible to a great extent. > Also, interfaces allow static final members, so today's static final > singleton instances of Tables, Fields, etc will probably still be > available, too. > > Managing those types is up to the client code. These things can be > achieved one way or the other with frameworks like spring, for > instance. I don't know enough about my client's integrations of jOOQ, > but I don't think there will be major problems. > > > Maybe they could be an alternative to generated beans or bean > > implementations could be provided for the interfaces. > > That's a good point. With interfaces representing tables/fields, > client code can inject new implementations into jOOQ. I don't see the > immediate use-case, but I can imagine that this opens up new > possibilities... > > Have you had similar thoughts for QueryDSL? Your generated artefacts > are also modeled as classes, not interface, if I remember right? > > Cheers > Lukas
