Hello Chris,
No, I do not suggest to make it on per-field basis. As there can be
only one database per PU, can it become a session property?
thanks,
-marina
Christopher Delahunt wrote:
> 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
>>>>
>>>>
>>>>
>>