HHH-11898: more "empty" composite issues
by Gail Badner
I realized that ComponentType#isEqual as well as #isSame, #compare,
#isDirty, and #isModified do not treat empty composites as equivalent to
null in the following cases:
1) the composite has a primitive attribute;
2) the composite has a singular attribute that gets initialized to a
non-null (or non-default primitive) value when the composite is constructed;
3) the composite has a plural attribute.
It would be straightforward to compare a primitive value in a composite
value with the default for the primitive type (e.g, comparing an int
property value with 0 instead of null).
I think it is reasonable to have Hibernate assume that a composite with
Object attributes set to null and primitive values set to its default value
to be considered an empty composite.
I am a little concerned that a primitive value that happens to be set to
the default could be a "real" value intended to be persisted, so I would
like to propose logging a warning
when hibernate.create_empty_composites.enabled=true and a composite has a
primitive value. The message would mention the ambiguity and recommend
using a non-primitive attribute instead.
Regarding 2), here are some examples of a singular attribute initialized to
a non-null (or non-default primitive) value when the composite is
constructed
Examples:
boolean isAvailable = true;
Integer length = -1;
Date created = new Date();
double random = Math.random();
IMO, Hibernate should throw an exception when
hibernate.create_empty_composites.enabled=true, because empty composites,
by definition, should have attributes that correspond to null columns.
At the very least, Hibernate should not automatically inject an
instantiated composite with initialized values when composite columns are
all null.
Regarding 3), if a composite contains a plural attribute, Hibernate
automatically injects a PersistentCollection into the empty composite.
ComponentType#isEqual, #isSame, #compare, #isDirty, and #isModified do not
take this into account when comparing the empty collection value with null.
IMO, this should be fixed. ComponentType#isEqual, #isSame, #compare,
#isDirty, and #isModified, should all assume an empty collection is
equivalent to null.
I suppose it could be helpful to add support for custom strategies for
determining if an instantiated composite is empty. For example, a strategy
could disregard some attributes (e.g., dates, random numbers), or have it's
own criteria for what an empty composite is. The default would be check all
attributes in the composite equal to null, primitive default, or empty
collection. I have no plans to pursue at this point though.
Anyone have any comments on any of this?
Thanks,
Gail
9 years, 1 month
Delivery reports about your e-mail
by Post Office
The original message was received at Fri, 25 Aug 2017 14:15:25 +0800
from lists.jboss.org [33.132.26.169]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
9 years, 1 month
DTO Projection support for native queries?
by Arnold Gálovics
Hi all,
I'm particularly interested in the usecase when you want to have a DTO
projection from a native query. Currently as far as I know this is not
supported through the JPA API.
If I say entityManager.createNativeQuery("...", SomeDTO.class) Hibernate
says SomeDTO is not an entity, at least that's what I remember.
Now I implemented the support for the Tuple type for native queries, so
implementing the support for DTO projections shouldn't be an issue.
Is there any reason why this is not supported yet?
Thanks in advance!
Best,
Arnold
9 years, 1 month
[ORM] About making delegating implementations abstract
by Guillaume Smet
Hi,
While updating OGM to use ORM 5.2, I found out that the delegating
implementations of a few classes are missing methods:
- AbstractDelegatingSessionBuilder
- AbstractDelegatingSessionFactoryBuilder
It stayed unnoticed because the classes are abstract so they don't complain
about missing methods.
Not sure what to do about this. At least one implementation of this sort of
things is not abstract
- SessionDelegatorBaseImpl - and, apparently, it allowed to detect missing
methods.
1/ Should we make all these classes not abstract even if their names make
it clear they should be?
2/ Another way to track it would be to have implementations of these
abstract classes in the tests. Even unused, it would break the build and
warn about this issue.
I'm more in favor of 2/ but I thought I might as well ask.
(I am preparing a PR to update these classes and also fix the hierarchy by
introducing a type parameter where required)
--
Guillaume
9 years, 1 month
