Am Donnerstag, 9. August 2012 17:00:07 UTC+2 schrieb Lukas Eder:
>> How are you loading the POJO into the record? Using Factory.newRecord()?
> > record.updateFrom( pojo );
> > This is a new method which is generated by my modified code generator
> that
> > copies every field.
>
> How is it different from this one?
>
> http://www.jooq.org/javadoc/latest/org/jooq/Record.html#from(java.lang.Object)
>
>
It doesn't use reflection. Since I know all the fields and getters and
setters, it's easy to generate a method that just calls all of them:
/**
* Copy the values of this record into another instance
*/
public void copyTo(com.avanon.blu.jooq.gen.tables.interfaces.adm.ILocation
other) {
other.setPK(getPK());
other.setXmlImportIdentifier(getXmlImportIdentifier());
...
}
/**
* Copy the values of another instance into this record
*/
public void
updateFrom(com.avanon.blu.jooq.gen.tables.interfaces.adm.ILocation other) {
setXmlImportIdentifier(other.getXmlImportIdentifier());
...
}
>
> >> [...] Any ideas?
> > Many:
> > - An update() and insert() method on the record or a parameter in the
> > store() method.
>
> That probably makes sense anyway. I have added feature request #1686 for
> this:
> https://github.com/jOOQ/jOOQ/issues/1686
>
> I prefer adding update() and insert() over store() argument flags for
> two reasons:
>
> - There is a risk of adding dozens of flags, eventually
> - They already exist, internally
>
> > - Add a field which says whether to INSERT or UPDATE. If it's not set or
> set
> > to AUTO, use the field flags.
>
> I assume you mean adding a field to Record? That would be redundant
> with the "changed" info of the PK, although more expressive in its
> intent.
>
Maybe it would make sense to combine all columns related to the PK into a
PK Java type, so the whole PK gets a single "has changed" flag.
But I have a feeling that this could cause nasty corner cases when someone
tries to manipulate the individual columns with setValue(field, ...);
> Among these three, clearly the first one. I'll think about it a bit
> more. The question here is whether the decision of updating/inserting
> should be done
>
> 1. At the moment when store() / insert() / update() is called
> 2. At the moment when a POJO is loaded into a record
>
> I'd like to explore some options around scenario 2, as well...
Well, Hibernate solves this like so: If the PK is null, the identity
generator is started to assign a PK (well, I simplify but you get the idea)
and an INSERT will happen. If the PK is not null, it will UPDATE.
This feels natural because it uses the assumption that you can't have a PK
unless the record has been read from the DB. And if you have a PK, then the
DB must already know about it.
So maybe a good solution would be to modify jOOQ to support a similar
behavior. With my suggested changes in the Configuration class, it would be
simple to add the PK generator to it. Everything else should then be a
purely internal change of the logic.
Regards,
Aaron
