-
Notifications
You must be signed in to change notification settings - Fork 681
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
Inconsistent column names for different databases (ie. H2 & PostgreSQL) #1658
Comments
I'm facing several similar issues trying to connect Exposed DSL against existing database scheme, unfortunately current implementation is so inconsistent in this area that I guess it won't work. I wouldn't even mind that much to quote it on my own, but: |
@dzikoysk I don't think inconsistent is the right term. It will try to use UPPERCASE or lowercase only depending on the used database. This shouldn't make any difference as When you have upper and lowercase mixed in your column name (like But, when you have a column name identical to a keyword (like So I see two possible solutions I could think of:
I would side with solution 1 but this would result in a higher impact on existing applications and might not be desired. Solution 2 may be a good trade-off. |
I've further looked into this and I think that this is indeed deeply linked to #683 @Tapac Do you have any opinion about the way Exposed should behave? I'm eager to work on a Pull Request for this problem if you want. But as we're talking about breaking changes I want to be extra careful. So even if you decide for any of the solutions from above (or something else), I would like to think a bit about how to incorporate the breaking changes. I have a few ideas:
I'd advise against option 1 (obviously not very elegant or user friendly) and option 3 (specify this on all tables manually is cumbersome and error-prone). |
For sure it cannot be solved by any kind of breaking change, so I'd personally go for opt-in option (4) to enforce explicit names for each identifier used in Exposed for tables/coulmns/indices names, even sth like |
@simboel Lines 65 to 74 in 990bff3
There's a keywords map available, so you could say that if the identified is in keywords, you return identity
I would say, let's give it a try and see where it breaks. The test suite should be quite comprehensive. |
@AlexeySoshin I think it'll probably break every single Postgres or H2 application (possibly more that I just haven't checked yet) that is relying on the current implementation as we're facing quotation. I think we might not be able to skip backward compatibility. |
Hi @simboel and thanks for all your thoughts on this issue. Regarding why
So that we can work towards the best solution for our users, I'd appreciate any insight you have regarding some questions I've detailed below: Essentially, I'm trying to understand the end-goal of solutions 3/4 (i.e. providing some sort of flag to enable explicit use of the user-defined name). Let's imagine in this scenario that the issue with keywords doesn't exist. i.e. The current behavior of Exposed, regardless of database, is that it correctly identifies a keyword, leaves the identifier case unchanged, and appropriately quotes it. If that were the current situation, what would be the benefit of introducing a flag on top of that?
So if the situation with quoted keywords is fixed, would there still be a need for a flag that I'm missing? If so, any example would be very much appreciated. |
Hi @simboel . Please note that this issue will be closed by the PR over the next few days. In the interest of continuing the discussion regarding a new feature flag that enables user-defined case sensitivity, please address any thoughts/design wishes in the related issue mentioned above (#683). Or in the dedicated YouTrack issue. Replying here might mean that I miss your response and I'd rather avoid that if possible. |
When defining a column that requires quotation the user will run into problems when changing databases (i.e. PostgreSQL for production and H2 for local tests).
Context:
Problem
When running the application, the quoted column names will be different depending on the target database. In H2 the column name will be changed to quoted UPPERCASE and when using PostgreSQL the column name will be changed to lowercase.
This means that the Flyway migration script will create a database that can only be read by H2 or PostgreSQL, but never both (when there is at least one column requiring quotation).
My current workaround is to iterate over all tables and columns and make sure, that no column will be quoted by Exposed. If it does, there will be an error and I manually change the column names.
Example
Result on H2
Result on PostgreSQL
Result
When using a flyway migration script, we will define the column name to
id
andname
. This will result in SQL exception when using H2 as there the column"NAME"
will be used instead.This problem will arise with all columns that match any of the roughly 500 keywords.
Expected result
Exposed should never change column names from the explicit value used in the table definition (at least when quotation is required). So the SQL should look like this:
Note that id and name are both identical to the definition in the Table.
If consistency between column names and generated sql is not undesired, Exposed should make sure, that the name will be identical to the column definition when quoting is required (ie. identical to a keyword).
The text was updated successfully, but these errors were encountered: