Re: [hibernate-dev] Native SQL Queries and Parameters
by Steve Ebersole
On Mon, Jun 18, 2018, 2:44 AM Yoann Rodiere <yrodiere(a)redhat.com> wrote:
> If by "basic types" you mean *all* basic types, including user-defined
> ones, I think it would make sense. Otherwise it sounds a bit limiting.
>
In 6.0 "user-defined type" means a very different thing generally speaking.
But I mean any BasicType, which may be a Hibernate class or a user class.
>
> There's the case of embedded IDs that might be considered as an exception,
> but I'm not sure there's a compelling reason to do so.
>
But this is my point. We can support composite parameters here. The
question really is whether we want to. In SQL there is no construct like
`(col1, col2) " ?` regardless of whether col1 and col2 are PK columns or
normal columns.
Really what I am asking is how closely we want native queries to look, feel
and work like a SQL query. Otherwise it's not really "native"
> By the way... it's not native queries, but it illustrates the challenges
> of supporting such composite types. There is currently some support for
> composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
> Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy, in
> a way that we had to circumvent in Hibernate Search [1]. In short they do
> not implement restrictions lexicographically, resulting in
> Restrictions.disjunction( Restrictions.gt( "myCompositeProperty", someValue
> ), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
> records, which may be counter-intuitive to some.
> Would it make sense for me to open a ticket? I'm not sure that's the kind
> of behavior one can change in 5, but maybe in a major such as 6...
>
You are talking about Hibernate's legacy criteria API which has been
deprecated for many years now and is already gone in 6. So no, I don't
want to see Jiras for that 😉
> [1] *https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b9...>https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src...
> <https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src...>**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b9...>*
>
>
> On Sat, 16 Jun 2018 at 20:20 Steve Ebersole <steve(a)hibernate.org> wrote:
>
>> While working on 6.0 I am wondering whether it makes sense to support
>> parameters of anything other than basic types. Personally I am thinking
>> not, but wanted to get other's opinions.
>>
>> The idea being that neither SQL nor JDBC define support for bind
>> parameters
>> of multiple values. So expecting to bind non-simple values is not
>> strictly
>> "native SQL" support.
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> --
> Yoann Rodiere
> yoann(a)hibernate.org / yrodiere(a)redhat.com
> Software Engineer
> Hibernate NoORM team
>
7 years, 4 months
Re: [hibernate-dev] Native SQL Queries and Parameters
by Yoann Rodiere
If by "basic types" you mean *all* basic types, including user-defined
ones, I think it would make sense. Otherwise it sounds a bit limiting.
There's the case of embedded IDs that might be considered as an exception,
but I'm not sure there's a compelling reason to do so.
By the way... it's not native queries, but it illustrates the challenges of
supporting such composite types. There is currently some support for
composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy, in
a way that we had to circumvent in Hibernate Search [1]. In short they do
not implement restrictions lexicographically, resulting in
Restrictions.disjunction( Restrictions.gt( "myCompositeProperty", someValue
), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
records, which may be counter-intuitive to some.
Would it make sense for me to open a ticket? I'm not sure that's the kind
of behavior one can change in 5, but maybe in a major such as 6...
[1] *https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
<https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b9...>https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src...
<https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src...>**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
<https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b9...>*
On Mon, 18 Jun 2018 at 09:44 Yoann Rodiere <yrodiere(a)redhat.com> wrote:
> If by "basic types" you mean *all* basic types, including user-defined
> ones, I think it would make sense. Otherwise it sounds a bit limiting.
>
> There's the case of embedded IDs that might be considered as an exception,
> but I'm not sure there's a compelling reason to do so.
>
> By the way... it's not native queries, but it illustrates the challenges
> of supporting such composite types. There is currently some support for
> composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
> Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy, in
> a way that we had to circumvent in Hibernate Search [1]. In short they do
> not implement restrictions lexicographically, resulting in
> Restrictions.disjunction( Restrictions.gt( "myCompositeProperty", someValue
> ), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
> records, which may be counter-intuitive to some.
> Would it make sense for me to open a ticket? I'm not sure that's the kind
> of behavior one can change in 5, but maybe in a major such as 6...
>
> [1] *https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b9...>https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src...
> <https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src...>**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b9...>*
>
>
> On Sat, 16 Jun 2018 at 20:20 Steve Ebersole <steve(a)hibernate.org> wrote:
>
>> While working on 6.0 I am wondering whether it makes sense to support
>> parameters of anything other than basic types. Personally I am thinking
>> not, but wanted to get other's opinions.
>>
>> The idea being that neither SQL nor JDBC define support for bind
>> parameters
>> of multiple values. So expecting to bind non-simple values is not
>> strictly
>> "native SQL" support.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> --
> Yoann Rodiere
> yoann(a)hibernate.org / yrodiere(a)redhat.com
> Software Engineer
> Hibernate NoORM team
>
--
Yoann Rodiere
yoann(a)hibernate.org / yrodiere(a)redhat.com
Software Engineer
Hibernate NoORM team
7 years, 4 months
Native SQL Queries and Parameters
by Steve Ebersole
While working on 6.0 I am wondering whether it makes sense to support
parameters of anything other than basic types. Personally I am thinking
not, but wanted to get other's opinions.
The idea being that neither SQL nor JDBC define support for bind parameters
of multiple values. So expecting to bind non-simple values is not strictly
"native SQL" support.
7 years, 4 months
Bytecode enhancement and inheritance
by Guillaume Smet
Hi Luis,
This question is related to https://hibernate.atlassian.net/browse/HHH-12601
.
AFAICS, the following case (e.g. having the fields defined in the parent
class and the laziness defined in the child class) is not working very well
with bytecode enhancement:
====
@Entity
public class RequestWithLazyEvents extends RelatedToEvents {
@ManyToMany(fetch = FetchType.LAZY)
@Fetch(FetchMode.SELECT)
public Set<Event> getEvents() {
return events;
}
}
@MappedSuperclass
public abstract class RelatedToEvents extends Base {
protected Set<Event> events = new LinkedHashSet<>();
public void setEvents(Set<Event> events) {
this.events = events;
}
}
====
By not working very well, I mean that the interceptor read/write methods
are defined in the child class but the getters and setters are not
intercepted because we only intercept the getters/setters if the fields are
defined in the current class:
See this method in PersistentAttributeTransformer and especially the last
test:
====
private boolean isEnhanced(String owner, String name, String desc) {
for ( FieldDescription enhancedField : enhancedFields ) {
if ( enhancedField.getName().equals( name )
&& enhancedField.getDescriptor().equals( desc )
&&
enhancedField.getDeclaringType().asErasure().getInternalName().equals(
owner ) ) {
return true;
}
}
return false;
}
====
(Note that supporting this case is not only a matter of removing the test)
I don't know if it's a case we want to support or not but I'm a bit worried
that we don't throw any error and the collection is not loaded at all (as
the rest of ORM supposes the enhancer will do the work).
You end up saving the collection in the database and when you get it back
the collection is always empty.
It can lead to serious data loss if you save the entity back to the
database thus I think it's somewhat critical to fix it.
WDYT?
--
Guillaume
7 years, 5 months
Re: [hibernate-dev] Multiple ResultSets from JDBC execution
by Steve Ebersole
Great that was actually my thought as well.
Anyone else?
On Fri, May 25, 2018, 12:03 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> I think that by default we should not assume the result sets are the same.
>
> Only if we provide a certain QueryHint (JPA) or call a specific method
> (Hibernate API) should we instruct Hibernate to process all ResultSets, in
> the same way, using a single ResultSetMapping.
>
> Vlad
>
>
>
> On Fri, May 25, 2018 at 12:15 AM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> I'm not saying to have a single result over all of the result
>> types/mappings. I am questioning whether the proper interpretation is to
>> uniformly process all result sets (assuming all result sets have same
>> columns and domain results) versus one per ResultSet.
>>
>> E.g, let's say we have a ProcedureCall that returns 2 ResultSets that
>> each should return some scalar value, lets say an Integer... Would this
>> require passing 2 result set mappings (the same one twice), one per
>> ResultSet. Or should use be able to just pass one mapping and have us
>> apply that one to each ResultSet?
>>
>> I think there are cases where both might make sense.
>>
>>
>>
>> On Thu, May 24, 2018, 2:42 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
>> wrote:
>>
>>> I this Hibernate forum discussion is on the same topic:
>>>
>>>
>>> https://discourse.hibernate.org/t/oracle-stored-procedure-with-multiple-o...
>>>
>>> So, if we have multiple REF_CURSOR sent back from a stored procedure,
>>> should we allow getResultList to be called multiple times, right?
>>>
>>> I don't think we should aggregate those to a single List<Object []> and
>>> allow a single getResultList call.
>>>
>>> Vlad
>>>
>>> On Wed, 23 May 2018, 15:52 Steve Ebersole, <steve(a)hibernate.org> wrote:
>>>
>>>> Execution of procedure calls, function calls and anonymous blocks can
>>>> all
>>>> lead to JDBC returning us multiple ResultSets.
>>>>
>>>> To account for this (for the first 2 anyway) JPA allows defining
>>>> multiple
>>>> ResultSetMapping references for the StoredProcesdureQuery.
>>>> Alternatively,
>>>> it allows specifying multiple "result classes". However, JPA is
>>>> silently
>>>> on how a provider is to treat these. Specifically, are these
>>>> "aggregated"
>>>> into a single "row reader"? Or do they represent individual row readers
>>>> specific to each expected ResultSet? In other words, are the ResultSets
>>>> heterogeneous or homogeneous?
>>>>
>>>> At the moment, Hibernate treats these by building a single aggregated
>>>> row
>>>> reader that it applies to reading all ResultSets. Like I said, JPA is
>>>> silent on what this "means" (and the TCK does not test it) so we are
>>>> free
>>>> to interpret this as we see fit.
>>>>
>>>> In retrospect I think the multiple ResultSetMappping case is probably
>>>> best
>>>> interpreted using the "distinct row reader per ResultSet" approach. I'm
>>>> not so convinced that is always the best interpretation of the multiple
>>>> result classes case. But I also think these should probably be handled
>>>> consistently.
>>>>
>>>> So what is everybody's preference here? Which interpretation do we
>>>> pick?
>>>> Worth it to make this configurable (per-SF + per-Query)?
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>
7 years, 5 months
JDK 11 Early Access build 15 is available for download.
by Rory O'Donnell
Hi Sanne,
**JDK 11 EA build 15 , *****under both the GPL and Oracle EA licenses,
is now available at **http://jdk.java.net/11**. **
*
* Newly approved Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o http://jdk.java.net/11/changes
*Notable changes in JDK 11 EA builds since last email:*
* b15 - JDK-8201627 <http://bugs.openjdk.java.net/browse/JDK-8201627>
- Kerberos sequence number issues
* b13 - JDK-8200146 <http://bugs.openjdk.java.net/browse/JDK-8200146>
- Removal of appletviewer launcher
o deprecated in JDK 9 and has been removed in this release
* b13 - JDK-8201793 <http://bugs.openjdk.java.net/browse/JDK-8201793>
- java.lang.ref.Reference does not support cloning
**
**
JEPs proposed to target JDK 11 (review ends 2018/05/31 23:00 UTC)
330: Launch Single-File Source-Code Programs
<http://openjdk.java.net/jeps/330>
JEPs targeted to JDK 11, so far
309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309>
318: Epsilon: A No-Op Garbage Collector
<http://openjdk.java.net/jeps/318>
320: Remove the Java EE and CORBA Modules
<http://openjdk.java.net/jeps/320>
321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321>
323: Local-Variable Syntax for Lambda Parameters
<http://openjdk.java.net/jeps/323>
324: Key Agreement with Curve25519 and Curve448
<http://openjdk.java.net/jeps/324>
327: Unicode 10 <http://openjdk.java.net/jeps/327>
328: Flight Recorder <http://openjdk.java.net/jeps/328>
329: ChaCha20 and Poly1305 Cryptographic Algorithms
<http://openjdk.java.net/jeps/329>
Finally, Initial TLSv1.3 implementation Released to the Open Sandbox.
Please note well: this branch is under
very active development and is not final by any means. Also note: by
releasing this code, we are not committing
a specific release or timeframe. We will continue development and fixing
bugs until the code is ready for inclusion
in the JDK. We welcome your feedback, more info [1]
Regards,
Rory
[1]
http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
7 years, 5 months
Hibernate ORM 5.2.18 to be the last in 5.2 series?
by Gail Badner
Now that 5.3 is out and is in the the process of being stabilized, and
active development is shifting to 6.0, it seems like a good time to wrap up
work on the 5.2 series.
Chris mentioned that he is planning to release 5.2.18 on Thursday.
Does anyone have a compelling reason why we should continue beyond 5.2.18?
7 years, 5 months
