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-r...
>
> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev