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.










share|improve this question
























  • 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















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.










share|improve this question
























  • 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













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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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


















  • 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












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.






share|improve this answer























  • 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










  • @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 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


















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.



enter image description here



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 codeon 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.






share|improve this answer

















  • 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











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
});


}
});














draft saved

draft discarded


















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.






share|improve this answer























  • 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










  • @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 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















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.






share|improve this answer























  • 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










  • @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 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













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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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 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










  • @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 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


















  • 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










  • @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 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
















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












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.



enter image description here



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 codeon 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.






share|improve this answer

















  • 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















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.



enter image description here



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 codeon 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.






share|improve this answer

















  • 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













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.



enter image description here



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 codeon 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.






share|improve this answer












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.



enter image description here



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 codeon 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.







share|improve this answer












share|improve this answer



share|improve this answer










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














  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







這個網誌中的熱門文章

Tangent Lines Diagram Along Smooth Curve

Yusuf al-Mu'taman ibn Hud

Zucchini