Hello Marina,
As it stands, it does use method access. The
shouldIgnoreCaseOnFieldComparisons' accessors exist now in the
DatabasePlatform, and unfortunately, where the flag is used (in
DatabaseField objects) the only access available is to the static
DatabasePlatform methods.
Refactoring would be very complicated, as the DatabasePlatform would need to
be set on each and every DatabaseField object created. Currently they can
be created all over the code, and the code that uses them does not have
access to the DatabasePlatform itself. In some areas, the DatabasePlatform
may not even have been set yet. It would be a major refactoring requiring
redesign for something that will not be overly needed. Users can easily get
around any problems by being consistent when specifying field names in their
applications - most users are already. Setting the flag would only be need
for users who reuse field names in the same table with different cases: ie
"User" and "user", something that is rather unlikely. If they do this and
don't set the flag, TopLink will not be able to distinguish the two fields
from one another like it does now.
Best Regards,
Chris
----- Original Message -----
From: "Marina Vatkina" <Marina.Vatkina_at_Sun.COM>
To: <persistence_at_glassfish.dev.java.net>
Sent: Thursday, September 07, 2006 5:12 PM
Subject: Re: issue 600, 832, 887 case sensitivity
> Hello Chris,
>
> I'm really concerned with per-vm flag. How complicated it to replace a
> flag access with a method call? (Which will then allow you to set it
> even on a session/PU bases ;)).
>
> About the name - either one doesn't actually identify what will be
> case-sensitive. "toplink.identifier.case-sensitive"?
>
> thanks,
> -marina
>
> Christopher Delahunt wrote:
>> Hello Marina,
>>
>> DatabaseField objects are created without any ties to the
>> databasePlatform, and there is currently no way of passing it to them as
>> they get created before the platform is set. Changing the flag to
>> operate on a per platform basis should added as a feature request - a
>> large level of refactoring core classes would be involved for something
>> that has traditionally been set at the JVM level in TopLink.
>>
>> "toplink.ignore-field-case" was a cut and paste mistake - this existed in
>> an earlier draft but changed since it affects table names as well as
>> fields. The added property will be either named "toplink.case-sensitive"
>> or "toplink.jdbc.case-sensitive" unless there are reasons against one or
>> the other shouldn't be used.
>>
>>
>> Best Regards,
>> Chris
>>
>> ----- Original Message ----- From: "Marina Vatkina"
>> <Marina.Vatkina_at_Sun.COM>
>> To: <persistence_at_glassfish.dev.java.net>
>> Sent: Thursday, September 07, 2006 3:40 PM
>> Subject: Re: issue 600, 832, 887 case sensitivity
>>
>>
>>> Chris,
>>>
>>> Can it be at least per platform? Otherwise we'll cause even more
>>> confusion
>>> for those apps that span multiple databases.
>>>
>>> Also, you start with a "toplink.case-sensitive" or
>>> "toplink.jdbc.case-sensitive" property, and then mention
>>> "toplink.ignore-field-case". How do they relate?
>>>
>>> thanks,
>>> -marina
>>>
>>>
>>> Christopher Delahunt wrote:
>>>
>>>> Hello,
>>>>
>>>> Glassfish has a number of open issues (gf bugs 600, 832 and 887 are
>>>> some examples) that have to do with field case sensitivitiy. I found
>>>> that there is already a static "shouldIgnoreCaseOnFieldComparisons"
>>>> flag on the DatabasePlatform that ensures field comparisons are done
>>>> using equalsIgnoreCase instead of equals - it currently defaults to
>>>> false.
>>>>
>>>> The fix will be to set this flag to true on the DatabasePlatform class,
>>>> and allow users to override it using either a "toplink.case-sensitive"
>>>> or "toplink.jdbc.case-sensitive" property. For users of case sensitive
>>>> databases, things will still work by default, as TopLink will still
>>>> pass the field names as defined to the driver and for them, case will
>>>> have to match or the database will complain or return unexpected
>>>> results. Users of case sensitive databases should only need to set the
>>>> flag to false if they use same string multiple times but with different
>>>> case in the database.
>>>>
>>>> The draw back is that the "toplink.ignore-field-case" setting will be
>>>> global, so will affect persistence units in the JVM. So there is no
>>>> way to override it for only one persistence unit.
>>>>
>>>> Please let me know if there are any concerns or if either of the
>>>> property names do not work, as I'd like to get this in tomorrow.
>>>>
>>>> Best Regards,
>>>> Chris
>>>
>>>
>