2:47 p.m.
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.
On Mon 23 Apr 2012 07:39:19 AM CDT, Łukasz Antoniak wrote:
If you are sure that only Oracle threads empty strings this way,
then
I will check if Oracle dialect is currently utilized.
Issue: https://hibernate.onjira.com/browse/HHH-7246
Regards,
Lukasz
W dniu 23 kwietnia 2012 14:00 użytkownik Steve Ebersole
<steve(a)hibernate.org> napisał:
> First, why do you need this?
>
> Second, they all distinguish between NULL and empty string. What Oracle
> does that is odd is to instead write empty strings as NULL when inserting or
> updating values.
>
>
> On Mon 23 Apr 2012 01:59:25 AM CDT, Łukasz Antoniak wrote:
>>
>> Hello team,
>>
>> I would like to add the following method to abstract Dialect class:
>>
>> /**
>> * Does this dialect distinguish between empty string and {@code NULL}
>> value?
>> *
>> * @return {@code true} if the database does not thread {@code NULL}
>> as an empty string; {@code false} otherwise.
>> */
>> public boolean supportsEmptyString() {
>> return true;
>> }
>>
>> I know that in Oracle dialect, it has to return false.
>>
>> Am I supposed to override it appropriately for other dialects before
>> committing my changes?
>> Any comments about naming? I couldn't come up with a better one.
>>
>> Regards,
>> Lukasz
>
>
> --
> steve(a)hibernate.org
> http://hibernate.org
--
steve(a)hibernate.org
http://hibernate.org
6:18 p.m.
New subject: Adding features to Dialect class
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.
8:23 p.m.
New subject: Adding features to Dialect class
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
--
steve(a)hibernate.org
http://hibernate.org
8:35 p.m.
New subject: Adding features to Dialect class
We figure out whether data of a single property has changed in
SinglePropertyMapper#mapToMapFromEntity(SessionImplementor,
Map<String, Object>, Object, Object). So the comparison is based on equals() method.
I wanted to change this to:
public boolean mapToMapFromEntity(SessionImplementor session, Map<String, Object>
data, Object newObj, Object oldObj) {
boolean dbLogicallyDifferent = true;
if ((session.getFactory().getDialect() instanceof Oracle8iDialect) && (newObj
instanceof String || oldObj instanceof String)) {
// Don't generate new revision when Oracle replaces empty string with NULL
during INSERT or UPDATE statements.
dbLogicallyDifferent = !(StringTools.isEmpty((String) newObj) &&
StringTools.isEmpty((String) oldObj));
}
return dbLogicallyDifferent && !Tools.objectsEqual(newObj, oldObj);
}
IMO there is no need to add an extra method to Dialect class. If it's only for Oracle,
I am happy to check it like above.
2:02 p.m.
New subject: Adding features to Dialect class
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/or...
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-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
--
steve(a)hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4379
days inactive
4386
days old
4 comments
3 participants
participants (3)
-
Eric Dalquist -
Steve Ebersole -
Łukasz Antoniak