-
Notifications
You must be signed in to change notification settings - Fork 350
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
SqlServerDialect should be case sensitive #914
Comments
Is SqlServer case insensitive even when the identifiers are quoted? If not going from My first instinct tells me that you should implement (or we should have) a separate dialect for this case. |
Yes SqlServer is case insensitive even when quoted. E.g. if I have SELECT * FROM dbo.MyObject
SELECT * FROM DBO.MYOBJECT
SELECT * FROM "dbo"."MyObject"
SELECT * FROM "DBO"."MYOBJECT" |
Ok, we'll go with your proposal. |
Quoting is important since it allows use of keywords as names. We do not change the letter casing. In a default setup the database does not care since it is case-insensitive. If configured to be case-sensitive it makes sense to pass on what ever letter casing there is, since you seem to care. Closes #1216 See #914
Quoting is important since it allows use of keywords as names. We do not change the letter casing. In a default setup the database does not care since it is case-insensitive. If configured to be case-sensitive it makes sense to pass on what ever letter casing there is, since you seem to care. Closes #1216 See #914
Scenario desription
Microsoft SQL Server is case insensitive by default, but can be changed to case sensitive when
COLLATION
server property is set (to some..._CS_...
value).Let's assume we have such SQL Server instance (e.g. with
COLLATION
set toLatin1_General_CS_AS
).When I declare my entity like this
then the following SQL statement is generated by default:
SELECT "MY_OBJECT"."MY_PROPERTY" AS "MY_PROPERTY" FROM "MY_OBJECT"
.If I want to have table and column names corresponding to class/field names, I have 2 options
@Table
and@Column
annotations to each fieldNamingStrategy
As I have a lot of entities and lot of fields,
NamingStrategy
seems like a better option, since I don't want all my entities to have duplicated literals like thisI'll implement a custom
NamingStrategy
Now the underscores are gone, but the select SQL looks like
SELECT "MYOBJECT"."MYPROPERTY" AS "MYPROPERTY" FROM "MYOBJECT"
.I.e. the identifiers get converted to uppercase which leads to
com.microsoft.sqlserver.jdbc.SQLServerException: Invalid object name 'MYOBJECT'
, because my DB is case sensitive and the correct table name isMyObject
notMYOBJECT
.Surprisingly, if I don't use a
NamingStrategy
but add explicit@Table
and@Column
annotations, it works as expected.Issue analysis
The problem is that the
SqlIdentifier
instances generated byRelationalPersistentEntityImpl
andBasicRelationalPersistentProperty
are of different types when names are specified explicitly and when derived from class/field names.While
DefaultSqlIdentifier
class (used when table/column names are explicitly specified) ignoresIdentifierProcessing
letter case standardization (is it intentional or a bug?) when generating SQL, theDerivedSqlIdentifier
pushes the identifier throughstandardizeLetterCase
method which causes the identifier to be converted to upper-case (asSqlServerDialect
returnsIdentifierProcessing.ANSI
).Solution proposal
I believe that
SqlServerDialect.getIdentifierProcessing()
should returnIdentifierProcessing.NONE
instead ofIdentifierProcessing.ANSI
.If the SQL Server is in case-insensitive mode, then it doesn't make any difference whether the generated SQL is
SELECT FROM "MY_OBJECT"
orSELECT FROM "My_Object"
(i.e. changing fromANSI
toNONE
won't break the case-insensitive mode).However, in case-sensitive mode, having
IdentifierProcessing
set toNONE
would help better control the object identifiers and it would save a lot of code duplication. I.e. in the scenario above I'd be able to use theNamingStrategy
as expected without having to duplicate each class and field name in explicit@Table
or@Column
annotation.The text was updated successfully, but these errors were encountered: