[hibernate-dev] Adding features to Dialect class

[Eric Dalquist]

Could this be a common enough issue that Hibernate includes a 
work-around type so that everyone doesn't have to write their own?

We've had to address this wonderful Oracle "feature" via a custom user 
type as well, ours is based on http://usertype.sourceforge.net/ and the 
NullSafeStringType and NullSafeStringColumnMapper are available here: 
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/dao/usertype/

Our approach is that any non-null string gets prefixed with _ when 
stored in the DB

-Eric

On 04/23/2012 01:23 PM, Steve Ebersole wrote:
> Personally I think people relying on this Oracle (mis-)behavior are
> just asking for problems.
>
> But lets say people do agree that we should handle this... so you add a
> method to Dialect to handle detect this environment... how do you plan
> on checking it?  Today it is the Types that are responsible for
> equality checking (I assume that is what Envers uses as well).  So I am
> just suggesting that the user supplying a custom
> FunkyOracleStringVarcharType Type implementation is probably a better
> option.  Unless I misunderstand how Envers is doing the equality
> checking and y'all do not use Types for that.
>
> On Mon 23 Apr 2012 11:18:44 AM CDT, Łukasz Antoniak wrote:
>> Totaly agree that expecting null to be equal to empty string in Java model is wrong.
>>
>> IMO he has spotted that when null string reference is replaced with an empty string, Envers creates new revision. From database
>> perspective (Oracle) two records does not differ in any way. This could be actually handled easily in Envers code. I thought that
>> it would be more elegant to add new dialect feature, but if this behavior is special to Oracle, there is no need.
>>
>> // Revision 1
>> em.getTransaction().begin();
>> StrTestEntity emptyEntity = new StrTestEntity("");
>> em.persist(emptyEntity);
>> em.getTransaction().commit();
>> // Should not generate revision after NULL to "" modification on Oracle. But now it does.
>> em.getTransaction().begin();
>> emptyEntity = em.find(StrTestEntity.class, emptyId);
>> emptyEntity.setStr(null);
>> em.merge(emptyEntity);
>> em.getTransaction().commit();
>>
>> Will use dev mailing list. Sorry for that.
>>
>> Steve Ebersole wrote:
>>    >   Their better option is to apply a Type for String that handles this.
>>    >   http://docs.jboss.org/hibernate/orm/4.1/manual/en-US/html_single/#types-registry
>>    >
>>    >   This is the type of thing we will be able to handle automatically in 5.0
>>    >
>>    >   But as for the forum user's exact question, personally I think him
>>    >   expecting null and empty string *in the java model* to be handled
>>    >   equally is just plain wrong.
>>    >
>>    >   P.S., these kinds of questions should be directed at the dev list so we
>>    >   can get everyone's input.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> --
> steve at hibernate.org
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev