Skip to content

Escaping case-sensitive columns [DATAJDBC-407] #628

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Aug 25, 2019 · 3 comments
Closed

Escaping case-sensitive columns [DATAJDBC-407] #628

spring-projects-issues opened this issue Aug 25, 2019 · 3 comments
Assignees
Labels
in: core Issues in core support type: bug A general bug

Comments

@spring-projects-issues
Copy link

Pavel Kapyla opened DATAJDBC-407 and commented

If one have an entity with case-sensitive columns (e.g. on Postgres database) DML statements generated by default implementation of CrudRepository product wrong statements.

@AllArgsConstructor
static class EntityWithCaseSensitiveColumnName {
   @Id @Column("\"primaryKey\"") Long id;
   @Column("\"ValueCol\"") String name;
   @Column("\"test_@123\"") String name2;
}
INSERT INTO entity_with_case_sensitive_column_name ("ValueCol", "test_@123", "primaryKey") VALUES (:ValueCol, :test_123, :primaryKey)

But binding parameters leads to exception:

No value supplied for the SQL parameter 'ValueCol': No value registered for key 'ValueCol'

because the parameterSource uses column names (with excaping commas) as keys for parameter values.

 

The same problem was partly addressed in DATAJDBC-334, now columns are correctly escaped, bad parameters problem still exists.

Actually the fix (DATAJDBC-381) solves the issue but padding with "_" is not needed in this case.

 

I hope it's possible to fix the problem in RC3


Affects: 1.0.10 (Lovelace SR10), 1.1 RC2 (Moore)

Issue Links:

  • DATAJDBC-381 Using backticks in column names leads to failure during INSERT with MySQL

  • DATAJDBC-386 Always quote identifiers

@spring-projects-issues
Copy link
Author

Jens Schauder commented

Does this problem still exists with DATAJDBC-381 (i.e. the current 2.0 Milestone)?

Make sure you register the proper Dialect which happens automatically with DATAJDBC-455

@spring-projects-issues spring-projects-issues added status: waiting-for-feedback We need additional information before we can continue type: bug A general bug in: core Issues in core support labels Dec 31, 2020
@spring-projects-issues
Copy link
Author

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@spring-projects-issues spring-projects-issues added the status: feedback-reminder We've sent a reminder that we need additional information before we can continue label Jan 7, 2021
@spring-projects-issues
Copy link
Author

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

@spring-projects-issues spring-projects-issues removed status: waiting-for-feedback We need additional information before we can continue status: feedback-reminder We've sent a reminder that we need additional information before we can continue labels Jan 14, 2021
mp911de added a commit that referenced this issue Feb 21, 2022
…verters.

Creating R2dbcCustomConversions without a dialect or StoreConversions can easily lead to misconfiguration that isn't immediately obvious because of missing store simple types. We now deprecated the constructor and have added guidance on how to properly create R2dbcCustomConversions that is associated with a dialect.

Closes #628
mp911de added a commit that referenced this issue Feb 21, 2022
Fix test.

See #628
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core support type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants