If changing the default to true doesn't break anything and solves all
the issues, I agree with Marina that we shouldn't doc it. It would only
confuse users and cause problems if someone changes the value to false.
June
Marina Vatkina wrote On 09/11/06 09:06,:
> Chris,
>
> Are you sure that nothing will break by changing the default value of the
> flag to true?
>
> I'm strongly opposed to exposing this flag exactly for the reasons you
> agreed
> to. Why is there the rush to implement something that might hurt the
> users,
> and we'll start explaining new problems instead of the old ones?
>
> Now, I've suggested another name. Did you miss it?
>
> thanks,
> -marina
>
> Christopher Delahunt wrote:
>
>> Hello,
>>
>> I think I have misrepresented what I'm doing. I am not implementing
>> new functionality, only exposing a flag that already exists by adding
>> a property. In addition, I am going to change the default value of
>> this flag to true, so that TopLink Essentials users will not
>> experience the issues described in bugs 600, 832 and 887 out of box.
>> I've filed 1127 to deal with refactoring the code to allow setting
>> the flag at a per PU basis instead of at a global level.
>>
>> Since I have not heard anything different, I will assume using
>> "toplink.jdbc.case-sensitive" as the property name is acceptable.
>>
>> Marina, you are correct in that if you deploy a PU that overrides the
>> default value (setting it to false), it will affect existing PUs
>> running in the VM.
>>
>>
>> Best Regards,
>> Chris
>>
>>
>> ----- Original Message ----- From: "Marina Vatkina"
>> <Marina.Vatkina_at_Sun.COM>
>> To: <persistence_at_glassfish.dev.java.net>
>> Sent: Friday, September 08, 2006 6:56 PM
>> Subject: Re: issue 600, 832, 887 case sensitivity
>>
>>
>>> Chris,
>>>
>>> This means that any PU in a VM will force it's settings on other PUs
>>> without a user knowledge. Will it also mean that the last PU being
>>> loaded will override settings for all others, and they might stop
>>> working?
>>>
>>> thanks,
>>> -marina
>>>
>>> Christopher Delahunt wrote:
>>>
>>>> Hello June,
>>>>
>>>> I did not answer as I was trying to research better options. As it
>>>> is, putting a global setting in the persistence.xml file may seem
>>>> illogical, but it ensures that it is known that the contained
>>>> persistence unit requires this functioanlity. It would also allow
>>>> us to changing the property in the future to only affect
>>>> persistence units with the property defined, without users having
>>>> to make changes to their applications.
>>>>
>>>> Other solutions/suggestions are welcome.
>>>>
>>>>
>>>> Best Regards,
>>>> Chris
>>>>
>>>> ----- Original Message ----- From: "Rebecca Parks"
>>>> <June.Parks_at_Sun.COM>
>>>> To: <persistence_at_glassfish.dev.java.net>
>>>> Sent: Friday, September 08, 2006 12:17 PM
>>>> Subject: Re: issue 600, 832, 887 case sensitivity
>>>>
>>>>
>>>>> No one has answered my question.
>>>>>
>>>>> June
>>>>>
>>>>> Rebecca Parks wrote On 09/07/06 12:56,:
>>>>>
>>>>>> If these properties are global, how do you set then in
>>>>>> GlassFish? It would be illogical to set them in the
>>>>>> persistence.xml file unless they were specific to a persistence
>>>>>> unit.
>>>>>>
>>>>>> June
>>>>>>
>>>>>> Marina Vatkina wrote On 09/07/06 12:40,:
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>