Hi Sven, You're having fun here? :-)
2013/4/5 Sven Jacobs <[email protected]>: > Hey, it's me again :) > > I'm now trying to create my own (temporary) table based on TableImpl > > class TemporaryTable extends TableImpl { > private final String idColumn; > > TemporaryTable(final String name, > final String idColumn) { > super(name); > this.idColumn = idColumn; > } > > @Override > public Identity getIdentity() { > return new Identity() { > @Override > public Table getTable() { > return TemporaryTable.this; > } > > @Override > public TableField getField() { > // What to return here?! How about TemporaryTable.this.field("ID")? > } > }; > } > > public <T> void addField(final String name, final DataType<T> dataType) { > createField(name, dataType, this); > } > } > > > but I don't know what to return at getField()? TableFieldImpl is > package-protected so I cannot instantiate it and I'm surely not going to > implement all methods of TableField and the ones inherited by Field ;) > > Am Freitag, 5. April 2013 16:25:22 UTC+2 schrieb Sven Jacobs: >> >> What I missed is that in AbstractTable#createField() a new instance >> TableFieldImpl is created and that this instance is added to the table's >> fields in the constructor of TableFieldImpl itself. >> I didn't expect this and to be honest think this is a bit dirty. Why does >> a TableField add itself to a table? Seems to be a mix-up of responsibility >> here. Wouldn't it be cleaner if the instance is added to the fields in >> createField()? >> >> Am Freitag, 5. April 2013 14:59:47 UTC+2 schrieb Sven Jacobs: >>> >>> This is a continuation of the discussion about the same issue. >>> >>> I recently discovered a problem when using insertInto() with returning() >>> and dynamically created tables, when not using jOOQ's code generation >>> feature. >>> I'm not using the code generation because the underlying database is only >>> known during runtime and might change. >>> >>> In that case the returned Record, which should contain the generated ID >>> of the newly inserted row, is always null. That's because in >>> AbstractStoreQuery#selectReturning() the check if (into.getIdentity() != >>> null) is always false since the dynamically generated table doesn't have an >>> identity set. >>> >>> // record is always null >>> Record record = create.insertInto(tableByName("MY_TABLE"), >>> fieldByName("FIELD1"), fieldByName("FIELD2")) >>> .values(values) >>> .returning(fieldByName("ID_FIELD")) >>> .fetchOne(); >>> >>> >>> Lukas pointed me to CustomTable and also made it possible to overwrite >>> getIdentity() by subtypes but I still don't understand how I can use this to >>> fix my problem. >>> Ok, I can now create an anonymous instance of CustomTable during runtime >>> that represents the table and also specify an identity, but how do I add >>> fields to my custom table? Because that would be the next issue of >>> selectReturning(). Utils.newRecord() expects the table to return its fields >>> via the fields() method that however is declared final in AbstractTable. >>> >>> I'm sure I'm just overlooking something here... Thanks your any help! >>> >>> Sven > > -- > 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.
