[hibernate-dev] AbstractStandardBasicType#getReplacement() prototype is incorrect since HHH-12054

Guillaume Smet guillaume.smet at gmail.com
Mon Jul 9 14:33:32 EDT 2018


Hi Gail,

Don't waste your time on it for now. We had an interesting discussion with
Yoann about it and I plan to revisit it.

I'll ping you when it's done.

Thanks.

-- 
Guillaume

On Thu, Jul 5, 2018 at 10:18 PM Gail Badner <gbadner at redhat.com> wrote:

> Hi Guillaume,
>
> Thanks for reminding me about this in my PR for HHH-12054 for backporting
> to 5.1.
>
> I'm planning to take a look at this, hopefully early next week.
>
> Regards,
> Gail
>
> On Wed, Jul 4, 2018 at 2:02 AM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Any thoughts on this one? Luis, I think your opinion would help.
>>
>> replace() being currently final, we cannot override it in child classes so
>> I tried another approach trying to avoid breaking what has been exposed to
>> the users:
>> https://github.com/hibernate/hibernate-orm/pull/2390
>>
>> It's not pretty but I think it's the best we can do.
>>
>> I still have a corner case when I don't know exactly what to do: what if
>> the original blob is null and the target blob is unfetched: should we set
>> the blob to null or initialize a new empty blob?
>>
>> The current situation is:
>> 1/ if original is null and target is null, it returns null
>> 2/ if original is null but target is not null, it returns an empty blob
>>
>> So the question is what should we do if original is null and target is
>> unfetched? Should we do 1/ or 2/?
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>


More information about the hibernate-dev mailing list