fields in JOOQ record not lining up when fetchInto
up vote
1
down vote
favorite
This is a weird problem that keeps happening across versions 3.10 and 3.11 of JOOQ (didn't try earlier versions). I fetch a record using fetchInto
, and when I print the record (or have debug on) the fields all print correctly. That is to say the value for field_x is correct.
The problem is that when I go to retrieve field_x using the record's getX
method, it returns the value from another field.
Below is some of the code we used.
return jooqDslContext.select(CL_USERS.fields())
.from(CL_USERS)
.join(THIRDPARTY_USER_XREF)
.on(THIRDPARTY_USER_XREF.USER_ID.eq(CL_USERS.CL_USER_ID))
.join(THIRDPARTY_USER_ID)
.on(THIRDPARTY_USER_ID.ID.eq(THIRDPARTY_USER_XREF.THIRDPARTY_ID))
.where(THIRDPARTY_USER_ID.EID.eq(eid))
.fetchOptionalInto(CL_USERS);
Here is the print of the record....
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------+ etc...
|remember_token |cl_user_id|ria_id|ria_user_id|ria_user_id_backup|cl_user_type|user_description|first_name | etc...
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------+ etc...
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...| 777777777| 777| 77777| {null}| {null}|{null} |xxxxxxxxxxxxxxxxxxxxxxxx| etc...
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------
notice the first_name
is populated. but when i print the first_name
using the getFirstName
method I get NULL
.
cur.getFirstName() = null
From the looks of it seems that there is a mismatch between the index number of the field.... the generated code thinks firstName
is field 6, in this case, but in reality it is field 8 (the 8th field in the toString()
output.
public byte getFirstName() {
return (byte) get(6);
}
EDIT: Adding more info.
How can this be reproduced?
Here is another example using a different code base from the example above. In this case I set the amount
field on the record object. But when I go to save it or print it out, the address
field is set instead.
TransactionsRecord tr = serviceDslContext.newRecord(Transactions.TRANSACTIONS);
tr.setAmount(new BigDecimal(10));
logger.debug("tr = {}", tr);
prints..
+------+-------+-------+...
|amount|account|address|...
+------+-------+-------+...
|{null}|{null} |*10 |...
+------+-------+-------+...
Link to the JOOQ generated code.
Can you post the DDL of the table?
CREATE TABLE `transactions` (
`account` VARCHAR(50) NOT NULL,
`address` VARCHAR(50) NOT NULL,
`amount` DECIMAL(42,10) NOT NULL,
`bip125-replaceable` VARCHAR(64) NOT NULL,
`blockhash` VARCHAR(64) NOT NULL,
`blockindex` INT(11) NOT NULL,
`blocktime` TIMESTAMP NULL DEFAULT NULL,
`category` VARCHAR(50) NOT NULL,
`confirmation` INT(11) NOT NULL,
`generated` TINYINT(1) NOT NULL,
`instantlock` TINYINT(4) NOT NULL,
`involvesWatchonly` TINYINT(4) NOT NULL,
`label` VARCHAR(50) NOT NULL,
`time` TIMESTAMP NULL DEFAULT NULL,
`timereceived` TIMESTAMP NULL DEFAULT NULL,
`txid` VARCHAR(64) NOT NULL,
`vout` INT(11) NOT NULL,
`walletconflicts` TEXT NULL,
`amount_in_usd` DECIMAL(42,10) NULL DEFAULT NULL,
`usd_exchange_rate` DECIMAL(42,10) NULL DEFAULT NULL,
PRIMARY KEY (`txid`),
INDEX `account_generated` (`account`, `generated`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
;
What database product and version are you using?
In the above case I am using MySQL 5.7.23 on AWS RDS. For the first example it was a variant of MySQL 5.6 on AWS RDS. Also, for the latter example, it has occurred on 5.7.14-google, we migrated recently to AWS.
java jooq
add a comment |
up vote
1
down vote
favorite
This is a weird problem that keeps happening across versions 3.10 and 3.11 of JOOQ (didn't try earlier versions). I fetch a record using fetchInto
, and when I print the record (or have debug on) the fields all print correctly. That is to say the value for field_x is correct.
The problem is that when I go to retrieve field_x using the record's getX
method, it returns the value from another field.
Below is some of the code we used.
return jooqDslContext.select(CL_USERS.fields())
.from(CL_USERS)
.join(THIRDPARTY_USER_XREF)
.on(THIRDPARTY_USER_XREF.USER_ID.eq(CL_USERS.CL_USER_ID))
.join(THIRDPARTY_USER_ID)
.on(THIRDPARTY_USER_ID.ID.eq(THIRDPARTY_USER_XREF.THIRDPARTY_ID))
.where(THIRDPARTY_USER_ID.EID.eq(eid))
.fetchOptionalInto(CL_USERS);
Here is the print of the record....
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------+ etc...
|remember_token |cl_user_id|ria_id|ria_user_id|ria_user_id_backup|cl_user_type|user_description|first_name | etc...
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------+ etc...
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...| 777777777| 777| 77777| {null}| {null}|{null} |xxxxxxxxxxxxxxxxxxxxxxxx| etc...
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------
notice the first_name
is populated. but when i print the first_name
using the getFirstName
method I get NULL
.
cur.getFirstName() = null
From the looks of it seems that there is a mismatch between the index number of the field.... the generated code thinks firstName
is field 6, in this case, but in reality it is field 8 (the 8th field in the toString()
output.
public byte getFirstName() {
return (byte) get(6);
}
EDIT: Adding more info.
How can this be reproduced?
Here is another example using a different code base from the example above. In this case I set the amount
field on the record object. But when I go to save it or print it out, the address
field is set instead.
TransactionsRecord tr = serviceDslContext.newRecord(Transactions.TRANSACTIONS);
tr.setAmount(new BigDecimal(10));
logger.debug("tr = {}", tr);
prints..
+------+-------+-------+...
|amount|account|address|...
+------+-------+-------+...
|{null}|{null} |*10 |...
+------+-------+-------+...
Link to the JOOQ generated code.
Can you post the DDL of the table?
CREATE TABLE `transactions` (
`account` VARCHAR(50) NOT NULL,
`address` VARCHAR(50) NOT NULL,
`amount` DECIMAL(42,10) NOT NULL,
`bip125-replaceable` VARCHAR(64) NOT NULL,
`blockhash` VARCHAR(64) NOT NULL,
`blockindex` INT(11) NOT NULL,
`blocktime` TIMESTAMP NULL DEFAULT NULL,
`category` VARCHAR(50) NOT NULL,
`confirmation` INT(11) NOT NULL,
`generated` TINYINT(1) NOT NULL,
`instantlock` TINYINT(4) NOT NULL,
`involvesWatchonly` TINYINT(4) NOT NULL,
`label` VARCHAR(50) NOT NULL,
`time` TIMESTAMP NULL DEFAULT NULL,
`timereceived` TIMESTAMP NULL DEFAULT NULL,
`txid` VARCHAR(64) NOT NULL,
`vout` INT(11) NOT NULL,
`walletconflicts` TEXT NULL,
`amount_in_usd` DECIMAL(42,10) NULL DEFAULT NULL,
`usd_exchange_rate` DECIMAL(42,10) NULL DEFAULT NULL,
PRIMARY KEY (`txid`),
INDEX `account_generated` (`account`, `generated`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
;
What database product and version are you using?
In the above case I am using MySQL 5.7.23 on AWS RDS. For the first example it was a variant of MySQL 5.6 on AWS RDS. Also, for the latter example, it has occurred on 5.7.14-google, we migrated recently to AWS.
java jooq
Is there a mismatch between the generated record and the generated table? I.e. does the record reference as many columns as the table?
– Lukas Eder
Nov 12 at 11:18
There are 44 fields in the record, and 44 columns in the table. I also had this on a separate project this weekend but in that case a new record is created using the DslContext and assigned the values using setFieldName methods. When I tried storing the record, the columns were not lined up to the fields. To fix it, I switched to set(FIELD, value) method for setting the values of the record.
– Jose Martinez
Nov 12 at 12:37
1
Sounds like a very weird edge case bug in the code generator. How can this be reproduced? Can you post the DDL of the table? What database product and version are you using?
– Lukas Eder
Nov 12 at 16:16
@LukasEder added some more info.
– Jose Martinez
Nov 13 at 4:29
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
This is a weird problem that keeps happening across versions 3.10 and 3.11 of JOOQ (didn't try earlier versions). I fetch a record using fetchInto
, and when I print the record (or have debug on) the fields all print correctly. That is to say the value for field_x is correct.
The problem is that when I go to retrieve field_x using the record's getX
method, it returns the value from another field.
Below is some of the code we used.
return jooqDslContext.select(CL_USERS.fields())
.from(CL_USERS)
.join(THIRDPARTY_USER_XREF)
.on(THIRDPARTY_USER_XREF.USER_ID.eq(CL_USERS.CL_USER_ID))
.join(THIRDPARTY_USER_ID)
.on(THIRDPARTY_USER_ID.ID.eq(THIRDPARTY_USER_XREF.THIRDPARTY_ID))
.where(THIRDPARTY_USER_ID.EID.eq(eid))
.fetchOptionalInto(CL_USERS);
Here is the print of the record....
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------+ etc...
|remember_token |cl_user_id|ria_id|ria_user_id|ria_user_id_backup|cl_user_type|user_description|first_name | etc...
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------+ etc...
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...| 777777777| 777| 77777| {null}| {null}|{null} |xxxxxxxxxxxxxxxxxxxxxxxx| etc...
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------
notice the first_name
is populated. but when i print the first_name
using the getFirstName
method I get NULL
.
cur.getFirstName() = null
From the looks of it seems that there is a mismatch between the index number of the field.... the generated code thinks firstName
is field 6, in this case, but in reality it is field 8 (the 8th field in the toString()
output.
public byte getFirstName() {
return (byte) get(6);
}
EDIT: Adding more info.
How can this be reproduced?
Here is another example using a different code base from the example above. In this case I set the amount
field on the record object. But when I go to save it or print it out, the address
field is set instead.
TransactionsRecord tr = serviceDslContext.newRecord(Transactions.TRANSACTIONS);
tr.setAmount(new BigDecimal(10));
logger.debug("tr = {}", tr);
prints..
+------+-------+-------+...
|amount|account|address|...
+------+-------+-------+...
|{null}|{null} |*10 |...
+------+-------+-------+...
Link to the JOOQ generated code.
Can you post the DDL of the table?
CREATE TABLE `transactions` (
`account` VARCHAR(50) NOT NULL,
`address` VARCHAR(50) NOT NULL,
`amount` DECIMAL(42,10) NOT NULL,
`bip125-replaceable` VARCHAR(64) NOT NULL,
`blockhash` VARCHAR(64) NOT NULL,
`blockindex` INT(11) NOT NULL,
`blocktime` TIMESTAMP NULL DEFAULT NULL,
`category` VARCHAR(50) NOT NULL,
`confirmation` INT(11) NOT NULL,
`generated` TINYINT(1) NOT NULL,
`instantlock` TINYINT(4) NOT NULL,
`involvesWatchonly` TINYINT(4) NOT NULL,
`label` VARCHAR(50) NOT NULL,
`time` TIMESTAMP NULL DEFAULT NULL,
`timereceived` TIMESTAMP NULL DEFAULT NULL,
`txid` VARCHAR(64) NOT NULL,
`vout` INT(11) NOT NULL,
`walletconflicts` TEXT NULL,
`amount_in_usd` DECIMAL(42,10) NULL DEFAULT NULL,
`usd_exchange_rate` DECIMAL(42,10) NULL DEFAULT NULL,
PRIMARY KEY (`txid`),
INDEX `account_generated` (`account`, `generated`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
;
What database product and version are you using?
In the above case I am using MySQL 5.7.23 on AWS RDS. For the first example it was a variant of MySQL 5.6 on AWS RDS. Also, for the latter example, it has occurred on 5.7.14-google, we migrated recently to AWS.
java jooq
This is a weird problem that keeps happening across versions 3.10 and 3.11 of JOOQ (didn't try earlier versions). I fetch a record using fetchInto
, and when I print the record (or have debug on) the fields all print correctly. That is to say the value for field_x is correct.
The problem is that when I go to retrieve field_x using the record's getX
method, it returns the value from another field.
Below is some of the code we used.
return jooqDslContext.select(CL_USERS.fields())
.from(CL_USERS)
.join(THIRDPARTY_USER_XREF)
.on(THIRDPARTY_USER_XREF.USER_ID.eq(CL_USERS.CL_USER_ID))
.join(THIRDPARTY_USER_ID)
.on(THIRDPARTY_USER_ID.ID.eq(THIRDPARTY_USER_XREF.THIRDPARTY_ID))
.where(THIRDPARTY_USER_ID.EID.eq(eid))
.fetchOptionalInto(CL_USERS);
Here is the print of the record....
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------+ etc...
|remember_token |cl_user_id|ria_id|ria_user_id|ria_user_id_backup|cl_user_type|user_description|first_name | etc...
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------+ etc...
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...| 777777777| 777| 77777| {null}| {null}|{null} |xxxxxxxxxxxxxxxxxxxxxxxx| etc...
+--------------------------------------------------+----------+------+-----------+------------------+------------+----------------+------------------------
notice the first_name
is populated. but when i print the first_name
using the getFirstName
method I get NULL
.
cur.getFirstName() = null
From the looks of it seems that there is a mismatch between the index number of the field.... the generated code thinks firstName
is field 6, in this case, but in reality it is field 8 (the 8th field in the toString()
output.
public byte getFirstName() {
return (byte) get(6);
}
EDIT: Adding more info.
How can this be reproduced?
Here is another example using a different code base from the example above. In this case I set the amount
field on the record object. But when I go to save it or print it out, the address
field is set instead.
TransactionsRecord tr = serviceDslContext.newRecord(Transactions.TRANSACTIONS);
tr.setAmount(new BigDecimal(10));
logger.debug("tr = {}", tr);
prints..
+------+-------+-------+...
|amount|account|address|...
+------+-------+-------+...
|{null}|{null} |*10 |...
+------+-------+-------+...
Link to the JOOQ generated code.
Can you post the DDL of the table?
CREATE TABLE `transactions` (
`account` VARCHAR(50) NOT NULL,
`address` VARCHAR(50) NOT NULL,
`amount` DECIMAL(42,10) NOT NULL,
`bip125-replaceable` VARCHAR(64) NOT NULL,
`blockhash` VARCHAR(64) NOT NULL,
`blockindex` INT(11) NOT NULL,
`blocktime` TIMESTAMP NULL DEFAULT NULL,
`category` VARCHAR(50) NOT NULL,
`confirmation` INT(11) NOT NULL,
`generated` TINYINT(1) NOT NULL,
`instantlock` TINYINT(4) NOT NULL,
`involvesWatchonly` TINYINT(4) NOT NULL,
`label` VARCHAR(50) NOT NULL,
`time` TIMESTAMP NULL DEFAULT NULL,
`timereceived` TIMESTAMP NULL DEFAULT NULL,
`txid` VARCHAR(64) NOT NULL,
`vout` INT(11) NOT NULL,
`walletconflicts` TEXT NULL,
`amount_in_usd` DECIMAL(42,10) NULL DEFAULT NULL,
`usd_exchange_rate` DECIMAL(42,10) NULL DEFAULT NULL,
PRIMARY KEY (`txid`),
INDEX `account_generated` (`account`, `generated`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
;
What database product and version are you using?
In the above case I am using MySQL 5.7.23 on AWS RDS. For the first example it was a variant of MySQL 5.6 on AWS RDS. Also, for the latter example, it has occurred on 5.7.14-google, we migrated recently to AWS.
java jooq
java jooq
edited Nov 13 at 4:28
asked Nov 9 at 19:45
Jose Martinez
6,58521942
6,58521942
Is there a mismatch between the generated record and the generated table? I.e. does the record reference as many columns as the table?
– Lukas Eder
Nov 12 at 11:18
There are 44 fields in the record, and 44 columns in the table. I also had this on a separate project this weekend but in that case a new record is created using the DslContext and assigned the values using setFieldName methods. When I tried storing the record, the columns were not lined up to the fields. To fix it, I switched to set(FIELD, value) method for setting the values of the record.
– Jose Martinez
Nov 12 at 12:37
1
Sounds like a very weird edge case bug in the code generator. How can this be reproduced? Can you post the DDL of the table? What database product and version are you using?
– Lukas Eder
Nov 12 at 16:16
@LukasEder added some more info.
– Jose Martinez
Nov 13 at 4:29
add a comment |
Is there a mismatch between the generated record and the generated table? I.e. does the record reference as many columns as the table?
– Lukas Eder
Nov 12 at 11:18
There are 44 fields in the record, and 44 columns in the table. I also had this on a separate project this weekend but in that case a new record is created using the DslContext and assigned the values using setFieldName methods. When I tried storing the record, the columns were not lined up to the fields. To fix it, I switched to set(FIELD, value) method for setting the values of the record.
– Jose Martinez
Nov 12 at 12:37
1
Sounds like a very weird edge case bug in the code generator. How can this be reproduced? Can you post the DDL of the table? What database product and version are you using?
– Lukas Eder
Nov 12 at 16:16
@LukasEder added some more info.
– Jose Martinez
Nov 13 at 4:29
Is there a mismatch between the generated record and the generated table? I.e. does the record reference as many columns as the table?
– Lukas Eder
Nov 12 at 11:18
Is there a mismatch between the generated record and the generated table? I.e. does the record reference as many columns as the table?
– Lukas Eder
Nov 12 at 11:18
There are 44 fields in the record, and 44 columns in the table. I also had this on a separate project this weekend but in that case a new record is created using the DslContext and assigned the values using setFieldName methods. When I tried storing the record, the columns were not lined up to the fields. To fix it, I switched to set(FIELD, value) method for setting the values of the record.
– Jose Martinez
Nov 12 at 12:37
There are 44 fields in the record, and 44 columns in the table. I also had this on a separate project this weekend but in that case a new record is created using the DslContext and assigned the values using setFieldName methods. When I tried storing the record, the columns were not lined up to the fields. To fix it, I switched to set(FIELD, value) method for setting the values of the record.
– Jose Martinez
Nov 12 at 12:37
1
1
Sounds like a very weird edge case bug in the code generator. How can this be reproduced? Can you post the DDL of the table? What database product and version are you using?
– Lukas Eder
Nov 12 at 16:16
Sounds like a very weird edge case bug in the code generator. How can this be reproduced? Can you post the DDL of the table? What database product and version are you using?
– Lukas Eder
Nov 12 at 16:16
@LukasEder added some more info.
– Jose Martinez
Nov 13 at 4:29
@LukasEder added some more info.
– Jose Martinez
Nov 13 at 4:29
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
It looks like the generated record you've posted was modified manually or using some post processors, or it was generated by a custom generator. Clearly, the generated table (correct order):
public class Transactions extends TableImpl<TransactionsRecord> {
...
public final TableField<TransactionsRecord, BigDecimal> AMOUNT =
createField("amount", org.jooq.impl.SQLDataType.DECIMAL(42, 10).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ACCOUNT =
createField("account", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ADDRESS =
createField("address", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
...
... and the generated record:
public class TransactionsRecord extends UpdatableRecordImpl<TransactionsRecord>
implements Record20<...> {
public void setAccount(String value) {
set(0, value);
}
public String getAccount() {
return (String) get(0);
}
public void setAddress(String value) {
set(1, value);
}
public TransactionsRecord() {
super(Transactions.TRANSACTIONS);
}
public TransactionsRecord(String account, String address, BigDecimal amount, ...) {
super(Transactions.TRANSACTIONS);
set(0, account);
set(1, address);
set(2, amount);
...
}
public BigDecimal getAmount() {
return (BigDecimal) get(2);
}
public String getAddress() {
return (String) get(1);
}
public void setAmount(BigDecimal value) {
set(2, value);
}
public void setBlockhash(String value) {
set(4, value);
}
...
... don't match. Look at how there are getters and setters before and after the constructor. Also, they are not in order! The official JavaGenerator
provided by jOOQ wouldn't generate such a class.
Notice, if you do want to modify generated code, you should either override JavaGenerator
or implement your own generator class.
Oh wow I wonder if its caused by IntelliJ? I only use the JOOQ generators. But I know when I commit code, IntelliJ reformats, rearranges, cleanup, and optimizes imports... those are the variousBefore Commit
options it has.
– Jose Martinez
Nov 13 at 12:40
Going to do a fresh generation, test the code, then apply IntelliJ's post-processor, and reproduce the problem.
– Jose Martinez
Nov 13 at 13:19
@JoseMartinez: But that would only explain the different order, not the different indexes used in the getters and the constructor.
– Lukas Eder
Nov 14 at 9:15
1
I think it does more than what we would expect an IDE should do. My guess is the re-arrange code feature is the culprit. The only generators I use areorg.jooq.util.GenerationTool
for 3.10 ororg.jooq.codegen.GenerationTool
for 3.11. I'll have the results of my tests tonight.
– Jose Martinez
Nov 14 at 12:30
See the answer I posted.
– Jose Martinez
Nov 15 at 2:17
add a comment |
up vote
1
down vote
After doing some testing it looks like the Rearrange code
feature in IntelliJ is messing up the JOOQ generated code. This can have dire consequences for code running in production. The Rearrange code
feature is displayed as an option in the Commit Changes window.
The testing consisted of running a test before and after the Rearrange code
feature. Below is the code.
TransactionsRecord tr = serviceDslContext.newRecord(TRANSACTIONS);
tr.setAmount(new BigDecimal(10));
logger.debug("tr = {}", tr);
If this code is executed before the Rearrange code
feature, that is right after JOOQ has generated the code, then the following is displayed...
+-------+-------+------+...
|account|address|amount|...
+-------+-------+------+...
|{null} |{null} | *10|...
+-------+-------+------+...
After IntelliJ executes Rearrange code
on the JOOQ generated code, this is the output...
+------+-------+-------+...
|amount|account|address|...
+------+-------+-------+...
|{null}|{null} |*10 |...
+------+-------+-------+...
It seems like the values stay in the right spot, but the fields that those values represent have shifted around.
2
Great finding! Thanks for documenting this. I'd also raise a bug to IntelliJ. This is quite severe.
– Lukas Eder
Nov 15 at 11:36
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53232350%2ffields-in-jooq-record-not-lining-up-when-fetchinto%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
It looks like the generated record you've posted was modified manually or using some post processors, or it was generated by a custom generator. Clearly, the generated table (correct order):
public class Transactions extends TableImpl<TransactionsRecord> {
...
public final TableField<TransactionsRecord, BigDecimal> AMOUNT =
createField("amount", org.jooq.impl.SQLDataType.DECIMAL(42, 10).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ACCOUNT =
createField("account", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ADDRESS =
createField("address", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
...
... and the generated record:
public class TransactionsRecord extends UpdatableRecordImpl<TransactionsRecord>
implements Record20<...> {
public void setAccount(String value) {
set(0, value);
}
public String getAccount() {
return (String) get(0);
}
public void setAddress(String value) {
set(1, value);
}
public TransactionsRecord() {
super(Transactions.TRANSACTIONS);
}
public TransactionsRecord(String account, String address, BigDecimal amount, ...) {
super(Transactions.TRANSACTIONS);
set(0, account);
set(1, address);
set(2, amount);
...
}
public BigDecimal getAmount() {
return (BigDecimal) get(2);
}
public String getAddress() {
return (String) get(1);
}
public void setAmount(BigDecimal value) {
set(2, value);
}
public void setBlockhash(String value) {
set(4, value);
}
...
... don't match. Look at how there are getters and setters before and after the constructor. Also, they are not in order! The official JavaGenerator
provided by jOOQ wouldn't generate such a class.
Notice, if you do want to modify generated code, you should either override JavaGenerator
or implement your own generator class.
Oh wow I wonder if its caused by IntelliJ? I only use the JOOQ generators. But I know when I commit code, IntelliJ reformats, rearranges, cleanup, and optimizes imports... those are the variousBefore Commit
options it has.
– Jose Martinez
Nov 13 at 12:40
Going to do a fresh generation, test the code, then apply IntelliJ's post-processor, and reproduce the problem.
– Jose Martinez
Nov 13 at 13:19
@JoseMartinez: But that would only explain the different order, not the different indexes used in the getters and the constructor.
– Lukas Eder
Nov 14 at 9:15
1
I think it does more than what we would expect an IDE should do. My guess is the re-arrange code feature is the culprit. The only generators I use areorg.jooq.util.GenerationTool
for 3.10 ororg.jooq.codegen.GenerationTool
for 3.11. I'll have the results of my tests tonight.
– Jose Martinez
Nov 14 at 12:30
See the answer I posted.
– Jose Martinez
Nov 15 at 2:17
add a comment |
up vote
1
down vote
accepted
It looks like the generated record you've posted was modified manually or using some post processors, or it was generated by a custom generator. Clearly, the generated table (correct order):
public class Transactions extends TableImpl<TransactionsRecord> {
...
public final TableField<TransactionsRecord, BigDecimal> AMOUNT =
createField("amount", org.jooq.impl.SQLDataType.DECIMAL(42, 10).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ACCOUNT =
createField("account", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ADDRESS =
createField("address", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
...
... and the generated record:
public class TransactionsRecord extends UpdatableRecordImpl<TransactionsRecord>
implements Record20<...> {
public void setAccount(String value) {
set(0, value);
}
public String getAccount() {
return (String) get(0);
}
public void setAddress(String value) {
set(1, value);
}
public TransactionsRecord() {
super(Transactions.TRANSACTIONS);
}
public TransactionsRecord(String account, String address, BigDecimal amount, ...) {
super(Transactions.TRANSACTIONS);
set(0, account);
set(1, address);
set(2, amount);
...
}
public BigDecimal getAmount() {
return (BigDecimal) get(2);
}
public String getAddress() {
return (String) get(1);
}
public void setAmount(BigDecimal value) {
set(2, value);
}
public void setBlockhash(String value) {
set(4, value);
}
...
... don't match. Look at how there are getters and setters before and after the constructor. Also, they are not in order! The official JavaGenerator
provided by jOOQ wouldn't generate such a class.
Notice, if you do want to modify generated code, you should either override JavaGenerator
or implement your own generator class.
Oh wow I wonder if its caused by IntelliJ? I only use the JOOQ generators. But I know when I commit code, IntelliJ reformats, rearranges, cleanup, and optimizes imports... those are the variousBefore Commit
options it has.
– Jose Martinez
Nov 13 at 12:40
Going to do a fresh generation, test the code, then apply IntelliJ's post-processor, and reproduce the problem.
– Jose Martinez
Nov 13 at 13:19
@JoseMartinez: But that would only explain the different order, not the different indexes used in the getters and the constructor.
– Lukas Eder
Nov 14 at 9:15
1
I think it does more than what we would expect an IDE should do. My guess is the re-arrange code feature is the culprit. The only generators I use areorg.jooq.util.GenerationTool
for 3.10 ororg.jooq.codegen.GenerationTool
for 3.11. I'll have the results of my tests tonight.
– Jose Martinez
Nov 14 at 12:30
See the answer I posted.
– Jose Martinez
Nov 15 at 2:17
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
It looks like the generated record you've posted was modified manually or using some post processors, or it was generated by a custom generator. Clearly, the generated table (correct order):
public class Transactions extends TableImpl<TransactionsRecord> {
...
public final TableField<TransactionsRecord, BigDecimal> AMOUNT =
createField("amount", org.jooq.impl.SQLDataType.DECIMAL(42, 10).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ACCOUNT =
createField("account", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ADDRESS =
createField("address", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
...
... and the generated record:
public class TransactionsRecord extends UpdatableRecordImpl<TransactionsRecord>
implements Record20<...> {
public void setAccount(String value) {
set(0, value);
}
public String getAccount() {
return (String) get(0);
}
public void setAddress(String value) {
set(1, value);
}
public TransactionsRecord() {
super(Transactions.TRANSACTIONS);
}
public TransactionsRecord(String account, String address, BigDecimal amount, ...) {
super(Transactions.TRANSACTIONS);
set(0, account);
set(1, address);
set(2, amount);
...
}
public BigDecimal getAmount() {
return (BigDecimal) get(2);
}
public String getAddress() {
return (String) get(1);
}
public void setAmount(BigDecimal value) {
set(2, value);
}
public void setBlockhash(String value) {
set(4, value);
}
...
... don't match. Look at how there are getters and setters before and after the constructor. Also, they are not in order! The official JavaGenerator
provided by jOOQ wouldn't generate such a class.
Notice, if you do want to modify generated code, you should either override JavaGenerator
or implement your own generator class.
It looks like the generated record you've posted was modified manually or using some post processors, or it was generated by a custom generator. Clearly, the generated table (correct order):
public class Transactions extends TableImpl<TransactionsRecord> {
...
public final TableField<TransactionsRecord, BigDecimal> AMOUNT =
createField("amount", org.jooq.impl.SQLDataType.DECIMAL(42, 10).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ACCOUNT =
createField("account", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
public final TableField<TransactionsRecord, String> ADDRESS =
createField("address", org.jooq.impl.SQLDataType.VARCHAR(50).nullable(false), this, "");
...
... and the generated record:
public class TransactionsRecord extends UpdatableRecordImpl<TransactionsRecord>
implements Record20<...> {
public void setAccount(String value) {
set(0, value);
}
public String getAccount() {
return (String) get(0);
}
public void setAddress(String value) {
set(1, value);
}
public TransactionsRecord() {
super(Transactions.TRANSACTIONS);
}
public TransactionsRecord(String account, String address, BigDecimal amount, ...) {
super(Transactions.TRANSACTIONS);
set(0, account);
set(1, address);
set(2, amount);
...
}
public BigDecimal getAmount() {
return (BigDecimal) get(2);
}
public String getAddress() {
return (String) get(1);
}
public void setAmount(BigDecimal value) {
set(2, value);
}
public void setBlockhash(String value) {
set(4, value);
}
...
... don't match. Look at how there are getters and setters before and after the constructor. Also, they are not in order! The official JavaGenerator
provided by jOOQ wouldn't generate such a class.
Notice, if you do want to modify generated code, you should either override JavaGenerator
or implement your own generator class.
edited Nov 13 at 10:43
answered Nov 13 at 10:37
Lukas Eder
131k70428934
131k70428934
Oh wow I wonder if its caused by IntelliJ? I only use the JOOQ generators. But I know when I commit code, IntelliJ reformats, rearranges, cleanup, and optimizes imports... those are the variousBefore Commit
options it has.
– Jose Martinez
Nov 13 at 12:40
Going to do a fresh generation, test the code, then apply IntelliJ's post-processor, and reproduce the problem.
– Jose Martinez
Nov 13 at 13:19
@JoseMartinez: But that would only explain the different order, not the different indexes used in the getters and the constructor.
– Lukas Eder
Nov 14 at 9:15
1
I think it does more than what we would expect an IDE should do. My guess is the re-arrange code feature is the culprit. The only generators I use areorg.jooq.util.GenerationTool
for 3.10 ororg.jooq.codegen.GenerationTool
for 3.11. I'll have the results of my tests tonight.
– Jose Martinez
Nov 14 at 12:30
See the answer I posted.
– Jose Martinez
Nov 15 at 2:17
add a comment |
Oh wow I wonder if its caused by IntelliJ? I only use the JOOQ generators. But I know when I commit code, IntelliJ reformats, rearranges, cleanup, and optimizes imports... those are the variousBefore Commit
options it has.
– Jose Martinez
Nov 13 at 12:40
Going to do a fresh generation, test the code, then apply IntelliJ's post-processor, and reproduce the problem.
– Jose Martinez
Nov 13 at 13:19
@JoseMartinez: But that would only explain the different order, not the different indexes used in the getters and the constructor.
– Lukas Eder
Nov 14 at 9:15
1
I think it does more than what we would expect an IDE should do. My guess is the re-arrange code feature is the culprit. The only generators I use areorg.jooq.util.GenerationTool
for 3.10 ororg.jooq.codegen.GenerationTool
for 3.11. I'll have the results of my tests tonight.
– Jose Martinez
Nov 14 at 12:30
See the answer I posted.
– Jose Martinez
Nov 15 at 2:17
Oh wow I wonder if its caused by IntelliJ? I only use the JOOQ generators. But I know when I commit code, IntelliJ reformats, rearranges, cleanup, and optimizes imports... those are the various
Before Commit
options it has.– Jose Martinez
Nov 13 at 12:40
Oh wow I wonder if its caused by IntelliJ? I only use the JOOQ generators. But I know when I commit code, IntelliJ reformats, rearranges, cleanup, and optimizes imports... those are the various
Before Commit
options it has.– Jose Martinez
Nov 13 at 12:40
Going to do a fresh generation, test the code, then apply IntelliJ's post-processor, and reproduce the problem.
– Jose Martinez
Nov 13 at 13:19
Going to do a fresh generation, test the code, then apply IntelliJ's post-processor, and reproduce the problem.
– Jose Martinez
Nov 13 at 13:19
@JoseMartinez: But that would only explain the different order, not the different indexes used in the getters and the constructor.
– Lukas Eder
Nov 14 at 9:15
@JoseMartinez: But that would only explain the different order, not the different indexes used in the getters and the constructor.
– Lukas Eder
Nov 14 at 9:15
1
1
I think it does more than what we would expect an IDE should do. My guess is the re-arrange code feature is the culprit. The only generators I use are
org.jooq.util.GenerationTool
for 3.10 or org.jooq.codegen.GenerationTool
for 3.11. I'll have the results of my tests tonight.– Jose Martinez
Nov 14 at 12:30
I think it does more than what we would expect an IDE should do. My guess is the re-arrange code feature is the culprit. The only generators I use are
org.jooq.util.GenerationTool
for 3.10 or org.jooq.codegen.GenerationTool
for 3.11. I'll have the results of my tests tonight.– Jose Martinez
Nov 14 at 12:30
See the answer I posted.
– Jose Martinez
Nov 15 at 2:17
See the answer I posted.
– Jose Martinez
Nov 15 at 2:17
add a comment |
up vote
1
down vote
After doing some testing it looks like the Rearrange code
feature in IntelliJ is messing up the JOOQ generated code. This can have dire consequences for code running in production. The Rearrange code
feature is displayed as an option in the Commit Changes window.
The testing consisted of running a test before and after the Rearrange code
feature. Below is the code.
TransactionsRecord tr = serviceDslContext.newRecord(TRANSACTIONS);
tr.setAmount(new BigDecimal(10));
logger.debug("tr = {}", tr);
If this code is executed before the Rearrange code
feature, that is right after JOOQ has generated the code, then the following is displayed...
+-------+-------+------+...
|account|address|amount|...
+-------+-------+------+...
|{null} |{null} | *10|...
+-------+-------+------+...
After IntelliJ executes Rearrange code
on the JOOQ generated code, this is the output...
+------+-------+-------+...
|amount|account|address|...
+------+-------+-------+...
|{null}|{null} |*10 |...
+------+-------+-------+...
It seems like the values stay in the right spot, but the fields that those values represent have shifted around.
2
Great finding! Thanks for documenting this. I'd also raise a bug to IntelliJ. This is quite severe.
– Lukas Eder
Nov 15 at 11:36
add a comment |
up vote
1
down vote
After doing some testing it looks like the Rearrange code
feature in IntelliJ is messing up the JOOQ generated code. This can have dire consequences for code running in production. The Rearrange code
feature is displayed as an option in the Commit Changes window.
The testing consisted of running a test before and after the Rearrange code
feature. Below is the code.
TransactionsRecord tr = serviceDslContext.newRecord(TRANSACTIONS);
tr.setAmount(new BigDecimal(10));
logger.debug("tr = {}", tr);
If this code is executed before the Rearrange code
feature, that is right after JOOQ has generated the code, then the following is displayed...
+-------+-------+------+...
|account|address|amount|...
+-------+-------+------+...
|{null} |{null} | *10|...
+-------+-------+------+...
After IntelliJ executes Rearrange code
on the JOOQ generated code, this is the output...
+------+-------+-------+...
|amount|account|address|...
+------+-------+-------+...
|{null}|{null} |*10 |...
+------+-------+-------+...
It seems like the values stay in the right spot, but the fields that those values represent have shifted around.
2
Great finding! Thanks for documenting this. I'd also raise a bug to IntelliJ. This is quite severe.
– Lukas Eder
Nov 15 at 11:36
add a comment |
up vote
1
down vote
up vote
1
down vote
After doing some testing it looks like the Rearrange code
feature in IntelliJ is messing up the JOOQ generated code. This can have dire consequences for code running in production. The Rearrange code
feature is displayed as an option in the Commit Changes window.
The testing consisted of running a test before and after the Rearrange code
feature. Below is the code.
TransactionsRecord tr = serviceDslContext.newRecord(TRANSACTIONS);
tr.setAmount(new BigDecimal(10));
logger.debug("tr = {}", tr);
If this code is executed before the Rearrange code
feature, that is right after JOOQ has generated the code, then the following is displayed...
+-------+-------+------+...
|account|address|amount|...
+-------+-------+------+...
|{null} |{null} | *10|...
+-------+-------+------+...
After IntelliJ executes Rearrange code
on the JOOQ generated code, this is the output...
+------+-------+-------+...
|amount|account|address|...
+------+-------+-------+...
|{null}|{null} |*10 |...
+------+-------+-------+...
It seems like the values stay in the right spot, but the fields that those values represent have shifted around.
After doing some testing it looks like the Rearrange code
feature in IntelliJ is messing up the JOOQ generated code. This can have dire consequences for code running in production. The Rearrange code
feature is displayed as an option in the Commit Changes window.
The testing consisted of running a test before and after the Rearrange code
feature. Below is the code.
TransactionsRecord tr = serviceDslContext.newRecord(TRANSACTIONS);
tr.setAmount(new BigDecimal(10));
logger.debug("tr = {}", tr);
If this code is executed before the Rearrange code
feature, that is right after JOOQ has generated the code, then the following is displayed...
+-------+-------+------+...
|account|address|amount|...
+-------+-------+------+...
|{null} |{null} | *10|...
+-------+-------+------+...
After IntelliJ executes Rearrange code
on the JOOQ generated code, this is the output...
+------+-------+-------+...
|amount|account|address|...
+------+-------+-------+...
|{null}|{null} |*10 |...
+------+-------+-------+...
It seems like the values stay in the right spot, but the fields that those values represent have shifted around.
answered Nov 15 at 2:16
Jose Martinez
6,58521942
6,58521942
2
Great finding! Thanks for documenting this. I'd also raise a bug to IntelliJ. This is quite severe.
– Lukas Eder
Nov 15 at 11:36
add a comment |
2
Great finding! Thanks for documenting this. I'd also raise a bug to IntelliJ. This is quite severe.
– Lukas Eder
Nov 15 at 11:36
2
2
Great finding! Thanks for documenting this. I'd also raise a bug to IntelliJ. This is quite severe.
– Lukas Eder
Nov 15 at 11:36
Great finding! Thanks for documenting this. I'd also raise a bug to IntelliJ. This is quite severe.
– Lukas Eder
Nov 15 at 11:36
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53232350%2ffields-in-jooq-record-not-lining-up-when-fetchinto%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Is there a mismatch between the generated record and the generated table? I.e. does the record reference as many columns as the table?
– Lukas Eder
Nov 12 at 11:18
There are 44 fields in the record, and 44 columns in the table. I also had this on a separate project this weekend but in that case a new record is created using the DslContext and assigned the values using setFieldName methods. When I tried storing the record, the columns were not lined up to the fields. To fix it, I switched to set(FIELD, value) method for setting the values of the record.
– Jose Martinez
Nov 12 at 12:37
1
Sounds like a very weird edge case bug in the code generator. How can this be reproduced? Can you post the DDL of the table? What database product and version are you using?
– Lukas Eder
Nov 12 at 16:16
@LukasEder added some more info.
– Jose Martinez
Nov 13 at 4:29