On 08/18/2010 11:49 PM, Caleb James DeLisle
wrote:
Sergiu Dumitriu wrote:
On 08/18/2010 04:43 PM, Anca Luca wrote:
> Hi Caleb,
>
> On 08/17/2010 09:15 PM, Caleb James DeLisle wrote:
>> I am going to commit this change and want to continue to discuss possible side
effects.
>>
>> I think this change will solve the bug causing database corruption when list
property is switched to relational storage
>> (I can't find this in jira anyone know the number? Sergiu?)
>>
>> I will be adding more tests and am ready to revert it at the first sign of
trouble.
> I haven't had time to look at the issue to be able to cast a vote
> knowing what I am saying but
>
> i don't agree with this approach. please don't.
One thing that will break is HQL queries hardcoded on StringProperty.
I thought
about this but it seemed to be acceptable since the only time anything would break is when
the input
exceeded 255 chars and in such cases the old behavior was to blow up with a database
error.
Well, not quite.
Before:
X edits a document, inputs a long value, tries to save: error (not the
ugly exception that gets thrown now, but a nice error message which
mentions the problem nicely). User inputs a shorter text, saves,
everyone is happy.
After:
X edits a document, inputs a long value, saves, but now the livetable
which lists that kind of documents doesn't filter or order correctly on
that column anymore.
I'm not totally convinced that this change is a good one and since you and Anca
disagree with it, I'll
pursue other avenues for long password hash handling.