Can the DefaultRecordMapper
work case insensitive?
The reason for the question is that Oracle
and H2
have the default behavior
of captilazing identifiers if not quoted (see https://seeq.atlassian.net/wiki/spaces/KB/pages/443088907/SQL+Column+Names+and+Case+Sensitivity and https://community.oracle.com/tech/developers/discussion/895094/is-there-anyway-to-make-oracle-field-names-case-insensitive-or-is-it-just). Unlike SQL Server
which uses the case sensitivity as the table was created.
The case sensitivity of the SQL output then does not match with the field of the POJO for Oracle and H2.
The only 2 solutions I could think of are:
ITEMUNIT as "itemUnit"
).The first solution however has a disadvantage. In case fetch
is used instead of fetchInto
to work raw
with the result, the get
method for a column value would need the alias too. So, the developer needs to know that there
is a distinction between using the helper method only for fetchInto
and the normal select
for fetch
.
Have I missed something? Is there a better/easier solution to this?
I have found https://www.jooq.org/doc/latest/manual/sql-building/dsl-context/custom-settings/settings-name-style/ but this does not solve the problem.
You can't make the DefaultRecordMapper
case insensitive, there's currently (jOOQ 3.16) no such configuration, and there aren't any plans on implementing this as it seems unnecessary, except for edge cases like yours.
Some takes:
ITEMUNIT
, then why not call your attribute itemunit
? It's the most canonical translation. You're not really gaining much by making that artificially camel cased here, but not snake cased thereitemUnit
, then why not consistently name your database column ITEM_UNIT
as well?In both of the above approaches, you wouldn't require case insensitivity as a workaround, but rather, have consistent naming across your database and application.
If the above isn't viable, you can still use various means to work around this:
@Column
annotation, which jOOQ supportsITEMUNIT AS ITEM_UNIT
for everyoneDefaultRecordMapper
, but that's laborious (you don't have to alias all columns, just the ones that are inconsistently named)DefaultRecordMapper
behaviour using a RecordMapperProvider
RecordMapper
created using Records::mapping
, e.g. fetch(mapping(POJO::new))
, assuming your POJO has a constructor accepting all fieldsBut in all of this, I think the underlying problem is the naming inconsistency. It would be far easier if you just named the column/attribute consistently. There's no value in making this particular distinction, it just causes trouble.