--
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 jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
1. One conversion that would be useful to have is the ability to convert from POJOs to Records and vice versa.On occasion I need to roll out my own POJO because our data is represented different at the service layer then how the datais actually stored, but I find myself using the autogenerated records and POJOs a good bit. It would be nice if there was an easy way to going from say:TableNameRecord --> TableName (pojo) and back.
class TableNameRecord extends UpdatableRecordImpl {...public TableNamePojo intoTableNamePojo() { ... }public void fromTableNamePojo(TableNamePojo pojo) { ... }}
It varies on my use case but I tend to usually fetchInto( . class) and most of the the class passed in is either the record or pojo that was generated by jooq.
class TableNameRecord extends UpdatableRecordImpl {...
public static RecordMapper<TableNameRecord, TableNamePojo> mapper() { ... }
}
dsl.select(...).from(...).fetchInto(TableNameRecord.mapper())
--
JOOQ has been really helpful. Like others have shared, I think mapping is where I spend some considerable amount of time when using Jooq. I have not really been leveraging JPA column annotation (appears you have or will be deprecating support).
I have had to develop utilities to support mapping with the help of Modelmapper library. For queries with multiple joins, how do you effectively deal with duplicate records in results (from resulting joins) and have them mapped to collection of different pojos without duplicates with current mapping strategies? With multiple selects, I can make do with the simplistic mappings but that is like going N + 1 queries. I will like to know how folks are dealing with this without too many code duplication or if there are libraries that can help or examples.
On a side note I find the amount of options (methods available, overloaded etc) when using jooq api to be a distraction. Sometimes get the sense I don't know enough about the tool.
What's your biggest "itch" in the jOOQ API, which jOOQ could "scratch", or rather, make go away by adding new convenience API?
On Thu, Jul 7, 2016 at 12:16 AM, Lukas Eder <lukas...@gmail.com> wrote:What's your biggest "itch" in the jOOQ API, which jOOQ could "scratch", or rather, make go away by adding new convenience API?
One that I hit yesterday, using fetchOne() which returns a null if absent, error if more than 1. What I would ideally have had was "fetchUnique" which would error on anything BUT 1 result, or a "fetchOptional".
"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
--
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 jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
that being said, this is "our" needs, it doesn't necessarily make sense for Jooq in general. Just passing on our use case in case it resonates with others and feedback was requested. :)
DSL.using(configuration).execute(CUSTOMER.insert(name, street1, ...));
DSL.using(configuration).executeInsert(new CustomerRecord(name, street1, ...));
DSL.using(configuration).insertInto(CUSTOMER).set(new CustomerRecord(name, street1, ...));
DSL.using(configuration)
.loadInto(CUSTOMER)
.loadRecords(new CustomerRecord(name, street1, ...))
.fields(CUSTOMER.fields())
.execute();
Result<CustomerRecord> result = DSL.using(configuration).newResult(CUSTOMER);
result.add(new CustomerRecord(name, street1, ...));
String inserts = result.formatInsert();
Table<?> join = BASE_TABLE;if (something)join = join.join(OTHER_TABLE).on(condition);if (somethingElse)join = join...;
DSL.using(configuration).execute(CUSTOMER.insert(name, street1, ...));
--
You received this message because you are subscribed to a topic in the Google Groups "jOOQ User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jooq-user/7hfDlmEwfQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+...@googlegroups.com.
FilterEngine engine = new FilterEngine(request);
DSL.select(engine.getSelectFields())/* it's possible! :-) */
.from(engine.getFactTable())/* it's possible! :-) */
.joins(engine.getDimensionJoins())/* NOT possible :-( */
.where(engine.getWhereConditions())/* it's possible! :-) */
.groupBy(engine.getGroupByFields())/* it's possible! :-) */
.orderBy(engine.getSortFields());/* it's possible! :-) */
Usually not all the query parts are mobile parts, but normally dimension tables are joined if a filter is present in the incoming json...
Thanks!!!
--
You received this message because you are subscribed to a topic in the Google Groups "jOOQ User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jooq-user/7hfDlmEwfQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+...@googlegroups.com.
DSL.select(engine.getSelectFields())/* it's possible! :-) */
.from(engine.getFactTableWithJoinedDimensions())/* it's possible! :-) */
// .joins(engine.getDimensionJoins())
.where(engine.getWhereConditions())/* it's possible! :-) */
.groupBy(engine.getGroupByFields())/* it's possible! :-) */
.orderBy(engine.getSortFields());/* it's possible! :-) */
--
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 jooq-user+unsubscribe@googlegroups.com.
--
Cheers,
Lukas
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscribe@googlegroups.com.
INSERT INTO db.customer( account_number, cancel_date)VALUES ( 1, NOW())
wrapper.getCreate().insertInto( CUSTOMER, CUSTOMER.ACCOUNT_NUMBER, // int CUSTOMER.CANCEL_DATE) // joda DateTime.values( 1, SOMETHING); // What should this be).execute();
Collection<Object> x = new ArrayList<Object>(); x.add(1); x.add(DSL.field("NOW()", Timestamp.class)); try (KrJooqWrapper wrapper = new KrJooqWrapper(DbType.KRDB, true)){ wrapper.getCreate() .insertInto( CUSTOMER, CUSTOMER.ACCOUNT_NUMBER, CUSTOMER.CANCEL_DATE) .values( x ) .execute(); }
--
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 jooq-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "jOOQ User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jooq-user/7hfDlmEwfQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+unsubscribe@googlegroups.com.
- DSL.val("NOW()") -> returns a string, type mismatch
- DSL.field("NOW()", DateTime.class) -> returns a Field<DateTime> which isn't compatible
@Column(expression = "replace( '_', '-', col_bar) || 'replaced!' " name = "FOO" )
public fooSetter( String foo) { ...}
SELECT replace('_', '-', col_bar) || 'replaced!' AS "FOO"FROM my_table
ctx.select(replace("_", "-", MY_TABLE.COL_BAR).concat("replaced!").as("FOO"))
.from(MY_TABLE)
.fetchInto(MyPojo.class);
ctx.select()
.from(MY_TABLE)
.fetch()
.stream()
.map(r -> r.into(MyPojo.class).withFoo(p.getColBar().replace("_", "-") + "replaced!"))
.collect(toList());
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscribe@googlegroups.com.
What I've done for now is:
- extend the JavaGenerator to generate properties (i.e field/getter/setter) in generated records (or POJOs) based on foreign keys
- write code to fetch records from a table and its "children" tables, and then associate children records to their parent (that is create a graph) using generated setters
- write code to insert/update/merge/delete a graph of record objects, copying foreign key values from parent to children when needed
For fetching it's a lot less than what a MULTISET can offer I guess
but the idea was to have write capabilities too (so you can insert/update a graph right from deserialized JSON).
And for now I only handles one-to-one and one-to-many relationships.
Just to get the complete picture [...] What currently keeps you from using JPA?
Perhaps there's already a low-hanging feature request that could be extracted from the above and moved into core jOOQ.
You bet. Check this out:
I'm very curious about some examples of what you have done
------------
| SIMU |
|------------|
|PK: SIMU_ID |
------------
1
___________|___________
/ \
/ \
1 *
------------- ---------------------------
| SIMU_COST | | SIMU_OPERATION |
|-------------| |---------------------------|
| PK: SIMU_ID | | PK: SIMU_ID, OPERATION_ID |
| FK: SIMU_ID | | FK: SIMU_ID |
------------- ---------------------------
private SimuCostRecord cost;
private List<SimuOperationRecord> operation;
// and related accessors (getter/setter)
// KR: type of the PK of the parent (or root) table
// PR: type of the parent table
public abstract class TreeNode<KR extends Record, PR extends TableRecord<PR>> {...}
// SimpleNode assumes a Record1<K> primary key
TreeNode<Record1<Integer>, SimuRecord> NODE = SimpleNode
// parent table and its primary key
.one(SIMU, SIMU.SIMU_ID)
// one-to-one child with foreign key and accessors for a SimuCostRecord property
.toOne(SIMU_COST, SIMU_COST.SIMU_ID, SimuRecord::getCost, SimuRecord::setCost)
// one-to-many child with foreign key and accessors for a List<SimuOperationRecord> property
.toMany(SIMU_OPERATION, SIMU_OPERATION.SIMU_ID, SimuRecord::getOperation, SimuRecord::setOperation);
// Associations are retrieved from foreign and unique keys reported by jOOQ,
// and accessors are found by reflection.
TreeNode<?, SimuRecord> NODE = new ReflectNode<SimuRecord>(SIMU);
// Relationships targeting the Table "parentTable"
Collection<ForeignKey<?,?>> keys = parentTable
.getPrimaryKey()
.getReferences();
// Cardinality of relationship defined by ForeignKey "fk"
boolean unique = fk
.getTable()
.getKeys()
.stream()
.anyMatch(uk -> fk.getFields().containsAll(uk.getFields()));
private final static TreeNode<?, SimuRecord> NODE; // use one of the above method to create the tree
// assumes a DSLContext field "dsl" is available
@GET
public Collection<SimuRecord> query() {
return NODE.fetch(dsl);
}
@POST
public SimuRecord merge(SimuRecord parent) {
NODE.merge(dsl, parent);
return NODE.fetchOne(dsl, condition(intoPrimaryKey(parent)));
}
@DELETE
@Path("{id}")
public void delete(@PathParam("id") Integer id) {
NODE.delete(dsl, DSL.row(id));
}
Hi Lukas,Just to get the complete picture [...] What currently keeps you from using JPA?A long time ago, I used to use JPA to do very basic CRUD stuffs, and it was working fine.
But I began to issue less and less insert/updates, and more and more complex selects, and to be very frustrated with the "code-in-a-string" JPQL approach, the verbosity of CriteriaBuilder, the lack of type-safety, and the heaviness of JPA in general.
Then came jOOQ, and it was good, and then came Java 8 streams and collectors, and there was nothing else left to say.
Until I needed a dumb CRUD resource on objects spanning several tables, and the circle was complete.
Hence the idea to be able to occasionally CRUD simple object graphs with jOOQ - the keywords being "occasionally" and "simple".
But I must confess I had the nasty feeling to re-create a JPA engine when writing this code, so I may well be wrong in refusing to use JPA again.
Also I'm heavily relying on Key objects, and it's bothering me that they don't have any generic to represent their type. But I posted another topic about that.
You bet. Check this out:
Ok, you won. I suddenly feel so pointless with my tiny helper...
I'm very curious about some examples of what you have done
For the purpose of demonstration, here is a simple graph:
Maybe Record with additional fields (Field<Record> or Field<List<Record>>) can replace concrete TableRecord with additional properties. Saw some feature requests about this kind of field I'll need to check.
But then again, let's try not to write yet another JPA engine.
I've not included the actual fetch/merge/delete code nor the generator code, because I didn't manage to extract meaningful snippets. And this post is already long enough anyway, seems I've been carried away by enthusiasm ;)
But I may share once properly packaged in a more standalone lib, if you're interested.
Hi Thomas,
private final static TreeNode<?, SimuRecord> NODE<span style="color:rgb(102,102,0)" class="gmail-m_8753945
--
--
You received this message because you are subscribed to a topic in the Google Groups "jOOQ User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jooq-user/7hfDlmEwfQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+unsubscribe@googlegroups.com.
Thank you very much for your detailed elaborations, greatly appreciated!
My usual advice here is to do what also some of the JPA advocates advise to do: Mix both worlds. Write the query with jOOQ, but execute and map it with JPA:
https://www.jooq.org/doc/latest/manual/sql-execution/alternative-execution-models/using-jooq-with-jpa/using-jooq-with-jpa-entities
This was published just now:
https://arnaudroger.github.io/blog/2017/03/02/jooq-one-to-many-without-dto.html
In theory, and in my opinion, the perceived impedance mismatch is only a SQL language implementation detail, or missing feature:
https://blog.jooq.org/2015/08/26/there-is-no-such-thing-as-object-relational-impedance-mismatch/
Oh oh... That's a recursive tree structure. […] you could work around things by tricking and using recursive SQL, and then materialising the tree only in the client.
No need for actual foreign or unique keys here so it can be used with any schema.Be careful. That might kill your performance. These constraints are very useful when querying, especially when you query the entire tree.
You should definitely support materialising your tree from a flattened result set, which you produce using recursive CTE.
My thinking is (for insert):
- Insert the entire tree flattened in a bulk INSERT .. RETURNING
- Retreive all the generated IDs and associate them with the individual tree nodes in the client model
- Update the parent references in a bulk UPDATE or MERGE by joining an in-memory table containing the relationships to the actual table
That should be rather "easy."
But I may share once properly packaged in a more standalone lib, if you're interested.Absolutely interested!
My usual advice here is to do what also some of the JPA advocates advise to do: Mix both worlds. Write the query with jOOQ, but execute and map it with JPA:
https://www.jooq.org/doc/latest/manual/sql-execution/alternative-execution-models/using-jooq-with-jpa/using-jooq-with-jpa-entities
I had forgotten this “native query” stuff. I can indeed use JPA with SQL, so with jOOQ!
Glad you told me. I was starting to wonder how to use jOOQ to generate JPQL queries...
In theory, and in my opinion, the perceived impedance mismatch is only a SQL language implementation detail, or missing feature:https://blog.jooq.org/2015/08/26/there-is-no-such-thing-as-object-relational-impedance-mismatch/
Interesting thoughts… This will make me think for a while…
Oh oh... That's a recursive tree structure. […] you could work around things by tricking and using recursive SQL, and then materialising the tree only in the client.
Errr… what? That’s just a very simple tree… Three tables, two relations (one 1-1 and one 1-N). In what way is it recursive?
I also don’t get the recursive SQL… I know how it works for a hierarchy of elements of the same type (i.e inside one table), but with 3 different tables, without any self-reference… Am I missing something?
Or maybe you misunderstood my schematic? That would explain your enthusiasm for this ;) because modelling an actual recursive tree, that would be more of a challenge…
When you say “bulk”, do you mean batch operations? I was under the impression that batches cannot return results…
Also this definitely needs deferred constraints to work, right?
// Packaged query:
public class MyQuery {
public final Table<...> QUERY;
public final Field<Integer> FIELD;
public MyQuery(String alias) {
// The query
this.QUERY =
select(SOME_TABLE.SOME_FIELD)
.from(SOME_TABLE)
.asTable(alias);
// The fields of the query, aliased accordingly
this.FIELD = QUERY.field(SOME_FIELD);
}
}
// Usage:
MyQuery q1 = new MyQuery("hello");
MyQuery q2 = new MyQuery("world");
select(q1.FIELD, q2.FIELD).from(q1.QUERY.join(q2.QUERY).on(...));
public class MyQuery extends SomeKindOfTableImpl<...> {
public final static MyQuery MY_QUERY = new MyQuery();
public final Field<Integer> FIELD = createField("field", ...);
public MyQuery() {
setTheQuery(
select(anyExpression.as(FIELD))
...;
);
}
}
// And then use it as any other table:
select(MY_QUERY.FIELD).from(MY_QUERY);
// Or aliased:
MyQuery q = MY_QUERY.as("yop");
select(q.FIELD).from(q);
public abstract class DerivedTableImpl<R extends Record> extends TableImpl<R> {
/**
* Default constructor.<br>
* The underlying query must then be set by subclasses through {@code query()}.
*/
protected DerivedTableImpl(String name) {
super(name);
}
/**
* Copy constructor, to be used when implementing {@code as()} in subclasses.<br>
* The underlying query is copied from the given table.
*/
protected DerivedTableImpl(String name, DerivedTableImpl<R> other) {
super(name);
setWrapped(this, getWrapped(other));
}
/**
* Sets the underlying query.<br>
* Should be called by subclasses in their (not copy) constructor.
*/
protected DerivedTableImpl<R> query(Select<? extends R> query) {
setWrapped(this, createDerivedTable(query));
return this;
}
// Force subclasses to covariantly override this method
/** {@inheritDoc} **/
@Override
public abstract DerivedTableImpl<R> as(String as);
//////// BLACK MAGIC
/**
* Set the internal alias of a {@code TableImpl}, even though field and class are final and package-private.<br>
* Allow to control the {@code wrapInParentheses} flag, and to set the alias after the constructor call.
*/
private static <R extends Record> void setWrapped(TableImpl<R> table, Table<R> wrapped) {
Object alias = wrapped == null ? null : on("org.jooq.impl.Alias").create(wrapped, table.getName(), true).get();
on(table).set("alias", alias);
}
/**
* Get the table wrapped in the internal alias of a {@code TableImpl}.
*/
private static <R extends Record> Table<R> getWrapped(TableImpl<R> table) {
Object alias = on(table).get("alias");
return alias == null ? null : on(alias).call("wrapped").get();
}
/**
* Create a {@code DerivedTable} instance, even though the class is package-private.<br>
* Allow to get a clean {@code DerivedTable} without aliasing (unlike {@code Select.asTable()}).
*/
private static <R extends Record> Table<R> createDerivedTable(Select<? extends R> query) {
return Reflect.on("org.jooq.impl.DerivedTable").create(query).get();
}
}
I was starting to wonder how to use jOOQ to generate JPQL queries...Don't! :)
Modelling an actual recursive tree, that would be more of a challengeOK, I misunderstood.
No, I try to clearly distinguish between the terms "bulk" and "batch" (they're heavily overloaded in the blogosphere, unfortunately).- Bulk: Several rows per statement. This mostly optimises algorithms in the database.- Batch: Several statements per request. This mostly optimises network traffic to the database.
ColumnValueMap valMapper =
ColumnValueMap.create("OWNERSYS.OWNER")
.add(field("ID"), generatedSeqKey)
.add(field("ENTITY_ID"), owner.getEntityId().Value)
.add(field("NAME"), owner.getName())
.add(field("OFFICIAL_SOURCE"), owner.getOfficialSourceType().getValue())
.add(field("BUSINESS_TYPE_ID"), owner.getBusinessType().getValue())
.add(field("OWNER_TYPE_ID"), owner.getOwnerType().getValue())
.add(field("VALID_FROM"), new Timestamp(owner.getValidFrom().toInstant().getEpochSecond()
* 1000L))
.add(field("VALID_UNTIL"), new Timestamp(owner.getValidUntil().toInstant().getEpochSecond()
* 1000L))
.add(field("REGISTERED_TIME"), new Timestamp(owner.getRegisteredTime().toInstant().getEpochSecond()
* 1000L));
ctx.insertInto(table(valMapper.Table), valMapper.getColumns()).values(valMapper.getValues()).execute();
..
This is almost identical to what is already supported by JOOQ, the difference is that you get more compact code by mapping column and value in a single .add() method, thus the expression will become more compact, which again increases readability.
An example of using the ColumnFieldMapper on simple types:
..
Contact c = new Contact(0,"t_at_t.no", "99221144", "Mr Anonymous");
ColumnFieldMap<Contact>
mapper = new ColumnFieldMap<>(c, "OWNERSYS.CONTACT");
mapper.add(field("ID"), "Id").add(field("EMAIL"), "Email").add(field("PHONE"), "Phone").add(field("NAME"), "Name");
ctx.insertInto(table(mapper.Table), mapper.getColumns()).values(mapper.getValues()).execute();
Hello all,One thing I felt missing this week is an easy way to create a custom derived table.When writing a complex (sub-)query, I sometimes like to package it in its own class, together with its (usually aliases) fields.Here a very simple example:
// Packaged query:
public class MyQuery {
public final Table<...> QUERY;
public final Field<Integer> FIELD;
public MyQuery(String alias) {
// The query
this.QUERY =
select(SOME_TABLE.SOME_FIELD)
.from(SOME_TABLE)
.asTable(alias);
// The fields of the query, aliased accordingly
this.FIELD = QUERY.field(SOME_FIELD);
}
}
// Usage:
MyQuery q1 = new MyQuery("hello");
MyQuery q2 = new MyQuery("world");
select(q1.FIELD, q2.FIELD).from(q1.QUERY.join(q2.QUERY).on(...));The idea being that I can alias my packaged query very easily, almost as if it was a generated table.Not so useful here, but worth the trouble when the query has a lot of fields.
Hello Lukas,Don't apologize for the delay, we all have a day job (and a night life, hopefully) to keep us busy.
Plus, I think your response time already beats any other support ;)
Well, I thought about that again, and I was wondering.When using JPA to simplify a complex schema, writing (jOOQ) queries on the database level may hinder this simplification.
I mean, JPQL allows to stay on the JPA model side, not worrying about mapping details.
Would not some kind of jOOJPQL make sense in that case ?
For example, I have a very ugly schema with bad, incoherent column and table names, lots of room for @Embedded classes... It would be cool to have generated fields named after the JPA model, including embedded objects.
This example is only about generation but there is more to JPA... i.e you mentioned fetch joins earlier...Hope I'm not going over the dark side of something with this jOOJPQL talk...
Actually, I think implementing a recursive tree would be both easier and funnier (optimization-wise) than a regular entity tree.What a shame I've no use for that in my application!
--
I'm not 100% sure if I follow, but there is a feature request for embedded records to be generated:
https://github.com/jOOQ/jOOQ/issues/2530
MULTISET would have been the right solution (again). *Especially* in JPA, as that would be perfect for an ORM.
Dear group,Part of jOOQ's success is its incredible amount of convenience methods that help reduce the boiler plate code at your side. We do this with massive overloading of API, for instance, when you work with fetch(), you may have noticed how many different types of fetch() there are in jOOQ.
...
// Reusable consumer:public static final Consumer<Integer> SINGLE_UPDATE = i -> Preconditions.checkState(i == 1);// And then:DSL.using(config).transaction(t -> {using(t).insertInto(t).values(...).executeInto(SINGLE_UPDATE);});
--
Dear group,Part of jOOQ's success is its incredible amount of convenience methods that help reduce the boiler plate code at your side. We do this with massive overloading of API, for instance, when you work with fetch(), you may have noticed how many different types of fetch() there are in jOOQ.
--
--
1. One conversion that would be useful to have is the ability to convert from POJOs to Records and vice versa.On occasion I need to roll out my own POJO because our data is represented different at the service layer then how the datais actually stored, but I find myself using the autogenerated records and POJOs a good bit. It would be nice if there was an easy way to going from say:TableNameRecord --> TableName (pojo) and back.It varies on my use case but I tend to usually fetchInto( . class) and most of the the class passed in is either the record or pojo that was generated by jooq.--Samir Faci
--Thank you
Samir Faci
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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 jooq-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/7007e64b-daf1-496a-b7c8-fec78aee6d12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
public static <T> T optionalValueForField(Record record, Field<T> field) {
int i = record.fieldsRow().indexOf(field);
if (i < 0) {
return null;
}
return record.get(i, field.getType());
}
What's your biggest "itch" in the jOOQ API, which jOOQ could "scratch", or rather, make go away by adding new convenience API?All ideas welcome!Lukas
To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAJ7OkQ_c%2BNvU4%2Bj9_44ohX6w-_-tL_7vqewa8tZ5SJT5Ey-j4A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO7wSR3QzxEbKvu8gfvG1sBHPsvHyRjGEgOdtPWj-tFKig%40mail.gmail.com.