It's absolutely enough. It's a best effort.
I, for sure, do not want us checking this each and every time we need to
check. That's excessively unwarranted.
On Wed, Jul 26, 2017, 6:45 PM Gail Badner wrote:
> IIUC, the fix for HHH-7610 was supposed to have Hibernate treat null and
> empty compo
IIUC, the fix for HHH-7610 was supposed to have Hibernate treat null and
empty composite as equivalent, regardless of how
hibernate.create_empty_composites.enabled
is set. [1]
The application could instantiate empty embeddables itself, and Hibernate
should still treat those values as equivalent to
Ok, I have removed `NativeQuery#getQueryReturns`. Move along, nothing to
see here...
On Wed, Jul 26, 2017 at 8:17 AM Steve Ebersole wrote:
> Actually just thought of a 3rd option... Simply make `#getQueryReturns`
> return values when the returns are known ahead of time (when Class[] or
> resul
No I mean checking on start up similar to what we do for composite id
classes. So basically if this setting is enabled (treat all nulls == empty
composite) make sure that the composite overrides equals/hashCode.
On Wed, Jul 26, 2017 at 6:08 PM Gail Badner wrote:
> Hi Steve,
>
> IIUC, you are
Hi Steve,
IIUC, you are suggesting:
if ( !emptyValue.equals( null ) || emptyValue.hashCode() != 0 ) {
LOG.warn( ... );
}
I originally mentioned this issue with respect to Collection methods called
on collections of embeddable values, but it could apply to empty/null
embeddables in singular
Another unnecessary complexity I'd like discuss removing is the ability to
execute procedure/function calls via NativeQuery. The complexity is a
bunch of String parsing and token interpretation we need to do in order to
discovery this intention. Given that both JPA and Hibernate define
specific A
OK, I'll make sure Hibernate also treats an empty array element as
equivalent to null as well.
Vlad, thanks for correcting the documentation.
On Wed, Jul 26, 2017 at 7:38 AM, Vlad Mihalcea
wrote:
> The docs says:
>
> When it comes to arrays, there is quite a difference between Java arrays
> an
The docs says:
When it comes to arrays, there is quite a difference between Java arrays
and relational database array types (e.g. VARRAY, ARRAY). First, not all
database systems implement the SQL-99 ARRAY type, and, for this reason,
Hibernate doesn’t support native database array types. Second, Ja
Actually just thought of a 3rd option... Simply make `#getQueryReturns`
return values when the returns are known ahead of time (when Class[] or
result-set-mapping is provided when creating the `NativeQuery`).
On Wed, Jul 26, 2017 at 8:06 AM Steve Ebersole wrote:
> In the absence of discussion I
In the absence of discussion I am actually leaning toward simply removing
that `NativeQuery#getQueryReturns` method...
Going once
twice...
On Tue, Jun 27, 2017 at 10:54 AM Steve Ebersole wrote:
> For 6.0 we need to address a few problems with this method.
>
> First, although largely minor
That doc section is wrong. Vlad - can you fix that
We do in fact support arrays of all types including embeddables and
entities. However, we have always recommended to not use arrays for
entities as arrays cannot be lazy loaded (not even using bytecode
enhancement).
On Mon, Jul 24, 2017 at 6:29
"Requirement" - no. I think a warning in this case is perfectly fine.
As for JPA, it says nothing about embeddables and nulls.
On Sun, Jul 23, 2017 at 6:49 PM Gail Badner wrote:
> As of HHH-7610, Hibernate is supposed to treat null and empty embeddable
> values as equivalent.
>
> Should we add
12 matches
Mail list logo
