Hi Lukas, thanks for your patience...
Am Dienstag, 21. Juni 2016 13:53:21 UTC+2 schrieb Lukas Eder: > > Hello Christian, > > There are two steps to follow. > First, you have to introspect the primaryKey's columns via > UniqueKeyDefinition.getKeyColumns() > Then, you have to find out the applicable Java type via > ColumnDefinition.getType().getJavaType(). There you should have everything > you need. Perhaps, some debugging through the code generator might also > help to find out what API elements will return the most appropriate > information. You could even make use of JavaGenerator's internals in order > to generate imports for such types. > Aha, I will look into that, thanks a lot. > I'm not sure how you intend to model composite primary keys. It could be > done e.g. with a jOOλ Tuple[N] type (see https://github.com/jOOQ/jOOL) > Yep, that's the problem. First, I thought about solving it the JPA-way. But then again, this is not doable: Having a(n embedded) FooBarPk doesn't help when you want to do something like: dslContext.selectFrom(rTable).where(pkField.eq(source.primaryKey)) where - rTable is of type Table<R> (R extends UpdatableRecord<R>) - pkField is of type Field<PK> (PK extends Serializable) - source is of type IdentifiablePojo<PK> >From a quick look at jOOλ I don't know how it can be used here... Actually, in DAOImpl you use getId() which is generated via your generator. I guess it also works for composite primary keys, right? Is it possible to use this implementation also to implement getPrimaryKey()? Thanks and regards Christian -- 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/d/optout.
