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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>