[hibernate-dev] Friends with Java 9 - Hibernate Validator 5.2.3.Final is out
Hi, It's my pleasure to announce the release of Hibernate Validator 5.2.3.Final. This fixes several bugs, most notably it allows to use HV on Java 9. Check out the announcement for the details [1]. Cheers, --Gunnar [1] http://in.relation.to/2016/01/27/friends-with-java-9-hibernate-validator-523-out/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Configuration to support batching (or sorting) of DELETE statements efficiently
Just pesky things like resources ;) On Wed, Jan 27, 2016 at 12:43 AM Vlad Mihalcea wrote: > This must be done like insert but in reverse order. With inserts, we need > to add parents first and children after, because of the foreign key > constraints. > For delete, we need to group children first and delete them prior to > deleting parents. > > Is there something that prevents us from implementing this feature? > > Vlad > > On Wed, Jan 27, 2016 at 7:01 AM, Madhusudana Reddy Sunnapu < > smreddy2...@gmail.com> wrote: > > > Hi, > > > > Hibernate provides simple configuration properties to enable batch > inserts > > and updates using "hibernate.order_inserts" and "hibernate.order_updates" > > respectively. These setting allow hibernate to sort the insert and update > > statements and process them in batches efficiently. > > > > But we don't have such a configuration to sort or batch delete statements > > efficiently. Especially with CascadeType.DELETE we can see that delete > > statements are not batched effectively and could result in extra network > > calls to the database for deletion.(Refer: > > > > > http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/ > > ) > > > > So I am thinking wouldn't it be a good feature to have hibernate support > > similar configuration, say "hibernate.order_deletes", to enable batch > > deletes similar to updates and inserts. > > > > Cheers, > > Madhu. > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Configuration to support batching (or sorting) of DELETE statements efficiently
Then we can add this task as a feature request and see when we have some time to add support for it. Vlad On Wed, Jan 27, 2016 at 6:54 PM, Steve Ebersole wrote: > Just pesky things like resources ;) > > On Wed, Jan 27, 2016 at 12:43 AM Vlad Mihalcea > wrote: > >> This must be done like insert but in reverse order. With inserts, we need >> to add parents first and children after, because of the foreign key >> constraints. >> For delete, we need to group children first and delete them prior to >> deleting parents. >> >> Is there something that prevents us from implementing this feature? >> >> Vlad >> >> On Wed, Jan 27, 2016 at 7:01 AM, Madhusudana Reddy Sunnapu < >> smreddy2...@gmail.com> wrote: >> >> > Hi, >> > >> > Hibernate provides simple configuration properties to enable batch >> inserts >> > and updates using "hibernate.order_inserts" and >> "hibernate.order_updates" >> > respectively. These setting allow hibernate to sort the insert and >> update >> > statements and process them in batches efficiently. >> > >> > But we don't have such a configuration to sort or batch delete >> statements >> > efficiently. Especially with CascadeType.DELETE we can see that delete >> > statements are not batched effectively and could result in extra network >> > calls to the database for deletion.(Refer: >> > >> > >> http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/ >> > ) >> > >> > So I am thinking wouldn't it be a good feature to have hibernate support >> > similar configuration, say "hibernate.order_deletes", to enable batch >> > deletes similar to updates and inserts. >> > >> > Cheers, >> > Madhu. >> > ___ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in Oracle
Andrea and I discussed on IRC and since we were the only 2 involved and both agreed, that constitutes a quorum! :) So I am going to override Oracle12cDialect#contributeTypes (implicit Type determination) such that: - recognize byte[] as MaterializedBlobType (Types#BLOB) rather than BinaryType (Types#LONGVARBINARY) - recognize Byte[] as WrappedMaterializedBlobType (Types#BLOB) rather than WrapperBinaryType (Types#LONGVARBINARY). I am a very leery about the VARCHAR, LONG, CLOB side of it mainly because the approach to access data from a VARCHAR and a CLOB are so very different and we'd have to account for that at some point based on size, etc. Ultimately what I'd love to see is to expand the distinction between SqlTypeDescriptor and JavaTypeDescriptor and to piece them together (along with AttributeConverter, MutabilityPLan, etc) into a BasicType "just in time". The reason I bring this up in that this question is really a discussion about the resolution for a SqlTypeDescriptor given just a JavaTypeDescriptor. That's fundamentally what BasicTypeRegistry is about. But ultimately, breaking that down further and instead asking for the SqlTypeDescriptor given a JavaTypeDescriptor is more flexible. Especially when you start to consider that that question can much more easily incorporate size information and other "contextual" data. Anyway, that's long term... For now I will override #contributeTypes in Oracle12cDialect to provide the new registrations mentioned above. I will do this on master (5.1). IMO we should also consider backporting this, but wanted to get everyone's (anyone) thoughts first. Opinions? On Tue, Jan 26, 2016 at 11:48 AM Steve Ebersole wrote: > This has come up again under HHH-10345[1]. > > The original request here claims that Oracle have deprecated LONG ( > LONGVARCHAR) and LONG RAW (LONGVARBINARY). It refers to the 9i release > notes as "proof" of that[2]. The 9i release notes do mention LONG > (LONGVARCHAR) > datatype being deprecated. However, it does not mention LONG RAW. The > next 2 references it links are from 10g and 11i; both of these do mention > LONG RAW specifically being deprecated. So LONG was deprecated as of 9i. > It is a bit unclear exactly when LONG RAW was deprecated. > > Unfortunately Oracle has issues with both LONG and LOB forms. In fact the > list of restrictions for LONG and LONG RAW is incredibly long. As far as > I can tell newer Oracle releases have alleviated some of the crazier > "limitations" of LOB usage; but its unfortunately been many years since I > have "used Oracle in anger", so I do not really know the complete current > state of its LOB support. > > While I personally agree that we should not be retroactively changing our > legacy Oracle-based dialects to map LONGVARCHAR to (N)CLOB and LONGVARBINARY > to BLOB, I do think that is something we want to change moving forward. > Specifically, I wonder if Oracle12cDialect is "foward". We knew about > these deprecations when Oracle12cDialect was developed and clearly these > types are deprecated prior to Oracle 12c even if exactly when Oracle > deprecated them is a bit murky. So specifically I wonder if, for 5.1, we > ought to make this change for Oracle12cDialect. What do y'all think? > > > [1] - https://hibernate.atlassian.net/browse/HHH-10345 > [2] - > http://docs.oracle.com/cd/A91202_01/901_doc/server.901/a90120/ch4_dep.htm#6690 > > > > On Mon, Oct 17, 2011 at 6:11 PM Gail Badner wrote: > >> There is a discussion about direct binding (fast) and stream binding >> (slow) at [1]. I think it answers Scott's questions. Rather than repeating >> the info here, please take a look at the Oracle documentation ( >> http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#autoId18 >> ). >> >> After thinking about this more, I think we should keep the Oracle >> dialects as is. Here are my reasons: >> - Hibernate defines the text/image types consistent with how Oracle maps >> LONGVARCHAR/LONGVARBINARY; >> - the bug lies with Oracle; >> - Oracle has effectively deprecated valid SQL data types (LONGVARCHAR and >> LONGVARBINARY); >> - the migration from "text" to "materialized_clob" has already been >> documented since 3.5; "image" is a new type as of 3.6; >> - anyone actually using text/image with LONG/LONGRAW columns may run into >> new migration issues in Hibernate 4.0.0; more testing would need to be done >> to determine the true impact; >> - users can easily create a new dialect making the changes I mentioned >> earlier; >> - this avoids having to make a confusing recommendation (i.e., using >> Oracle11gDialect for accessing an Oracle 10g DB). >> >> Regarding Oracle tests, IMO, the tests using "text" and "image" should be >> disabled. If there is no similar test using clob/blob, it would be a good >> idea to add one. >> >> - Original Message - >> > From: "Łukasz Antoniak" >> > To: "Strong Liu" >> > Cc: "Scott Marlow" , "Gail Badner" < >> gbad...@redhat.com
[hibernate-dev] [Search] Travis support
Hi, As mentioned in our last discussion, I explored adding Travis support to Search. The diff is here: https://github.com/gsmet/hibernate-search/commit/cbd2c1fff05532974823da572795d53cb8b9d26a (yes it's short but it was a long road :)) I had to raise a bit the JGroups timeout for one test and had to fix TestRunnerStandalone so that it effectively uses the configuration from the profile (this change is not specific to Travis and should be committed anyway). The result is here: https://travis-ci.org/gsmet/hibernate-search What I like in Travis: - The CI configuration is code and is versioned - Parallelization with a *lot* of resources - The ability to build a test matrix very easily - Complete isolation as each build is run in its own Docker container What is less cool: - The only way to get the logs is to ship them to AWS S3 - that said, I did it and it's pretty straightforward as it's well integrated (I commented out the code in the .travis.yml for now) - It might seem less flexible as we are depending on the Travis infrastructure (for instance, I created a ticket to ask for the support of JDK 9: https://github.com/travis-ci/travis-ci/issues/5520) but in fact, you can do whatever you want: see https://github.com/Blazebit/blaze-persistence .travis.yml file for a comprehensive example So if we move to Travis, I think the regular builds could run on Travis and we could keep Jenkins for specific ones (deploy/release). I'll take a look at OGM tomorrow. Travis supports out of the box most of the NoSQL databases (https://docs.travis-ci.com/user/database-setup/) so I'm pretty curious to see how it goes. Thoughts? -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] JDBC warnings performance matter
Hi, The guys at Plumbr wrote an article about how MySQL JDBC warnings are handled by Hibernate: https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate I remember seeing this issue on StackOverflow too and I was curious if you want to tweak it a little bit. I also agree that relying on the log levels to prevent fetching warnings might come as a surprise to many users and we should document this behavior. We could also have a hibernate.jdbc.log.warnings boolean property to control whether we want to log those warnings or not. This way, if users set the logger level to WARN, they will see the logs generated by the framework stack and the JDBC warnings will be logged only if this configuration property is true. What do you think? Vlad ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Configuration to support batching (or sorting) of DELETE statements efficiently
I created this JIRA issue for this: https://hibernate.atlassian.net/browse/HHH-10483 Vlad On Wed, Jan 27, 2016 at 7:02 PM, Vlad Mihalcea wrote: > Then we can add this task as a feature request and see when we have some > time to add support for it. > > Vlad > > On Wed, Jan 27, 2016 at 6:54 PM, Steve Ebersole > wrote: > >> Just pesky things like resources ;) >> >> On Wed, Jan 27, 2016 at 12:43 AM Vlad Mihalcea >> wrote: >> >>> This must be done like insert but in reverse order. With inserts, we need >>> to add parents first and children after, because of the foreign key >>> constraints. >>> For delete, we need to group children first and delete them prior to >>> deleting parents. >>> >>> Is there something that prevents us from implementing this feature? >>> >>> Vlad >>> >>> On Wed, Jan 27, 2016 at 7:01 AM, Madhusudana Reddy Sunnapu < >>> smreddy2...@gmail.com> wrote: >>> >>> > Hi, >>> > >>> > Hibernate provides simple configuration properties to enable batch >>> inserts >>> > and updates using "hibernate.order_inserts" and >>> "hibernate.order_updates" >>> > respectively. These setting allow hibernate to sort the insert and >>> update >>> > statements and process them in batches efficiently. >>> > >>> > But we don't have such a configuration to sort or batch delete >>> statements >>> > efficiently. Especially with CascadeType.DELETE we can see that delete >>> > statements are not batched effectively and could result in extra >>> network >>> > calls to the database for deletion.(Refer: >>> > >>> > >>> http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/ >>> > ) >>> > >>> > So I am thinking wouldn't it be a good feature to have hibernate >>> support >>> > similar configuration, say "hibernate.order_deletes", to enable batch >>> > deletes similar to updates and inserts. >>> > >>> > Cheers, >>> > Madhu. >>> > ___ >>> > hibernate-dev mailing list >>> > hibernate-dev@lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in Oracle
Hi, Shouldn't we use the database metadata to know what SQL column type we are mapping to? I don't think we should do heuristic determination of types: Type result = metadata.getTypeResolver().heuristicType( typeName, typeParameters ); When Hibernate starts, we could inspect the underlying table JDBC metadata and get the actual SQL data types. This way we have both the Java type and the JDBC type and the entity property can get a Hibernate Type according to these two. Vlad On Wed, Jan 27, 2016 at 8:12 PM, Steve Ebersole wrote: > Andrea and I discussed on IRC and since we were the only 2 involved and > both agreed, that constitutes a quorum! :) > > So I am going to override Oracle12cDialect#contributeTypes (implicit Type > determination) such that: > >- recognize byte[] as MaterializedBlobType (Types#BLOB) rather than >BinaryType (Types#LONGVARBINARY) >- recognize Byte[] as WrappedMaterializedBlobType (Types#BLOB) rather >than WrapperBinaryType (Types#LONGVARBINARY). > > I am a very leery about the VARCHAR, LONG, CLOB side of it mainly because > the approach to access data from a VARCHAR and a CLOB are so very different > and we'd have to account for that at some point based on size, etc. > > Ultimately what I'd love to see is to expand the distinction > between SqlTypeDescriptor and > JavaTypeDescriptor and to piece them together (along with > AttributeConverter, MutabilityPLan, etc) into a BasicType "just in time". > The reason I bring this up in that this question is really a discussion > about the resolution for a SqlTypeDescriptor given just a > JavaTypeDescriptor. That's fundamentally what BasicTypeRegistry is about. > But ultimately, breaking that down further and instead asking for the > SqlTypeDescriptor given a JavaTypeDescriptor is more flexible. Especially > when you start to consider that that question can much more easily > incorporate size information and other "contextual" data. > > Anyway, that's long term... For now I will override #contributeTypes > in Oracle12cDialect > to provide the new registrations mentioned above. I will do this on master > (5.1). IMO we should also consider backporting this, but wanted to get > everyone's (anyone) thoughts first. Opinions? > > > On Tue, Jan 26, 2016 at 11:48 AM Steve Ebersole > wrote: > > > This has come up again under HHH-10345[1]. > > > > The original request here claims that Oracle have deprecated LONG ( > > LONGVARCHAR) and LONG RAW (LONGVARBINARY). It refers to the 9i release > > notes as "proof" of that[2]. The 9i release notes do mention LONG > (LONGVARCHAR) > > datatype being deprecated. However, it does not mention LONG RAW. The > > next 2 references it links are from 10g and 11i; both of these do mention > > LONG RAW specifically being deprecated. So LONG was deprecated as of 9i. > > It is a bit unclear exactly when LONG RAW was deprecated. > > > > Unfortunately Oracle has issues with both LONG and LOB forms. In fact > the > > list of restrictions for LONG and LONG RAW is incredibly long. As far > as > > I can tell newer Oracle releases have alleviated some of the crazier > > "limitations" of LOB usage; but its unfortunately been many years since I > > have "used Oracle in anger", so I do not really know the complete current > > state of its LOB support. > > > > While I personally agree that we should not be retroactively changing our > > legacy Oracle-based dialects to map LONGVARCHAR to (N)CLOB and > LONGVARBINARY > > to BLOB, I do think that is something we want to change moving forward. > > Specifically, I wonder if Oracle12cDialect is "foward". We knew about > > these deprecations when Oracle12cDialect was developed and clearly these > > types are deprecated prior to Oracle 12c even if exactly when Oracle > > deprecated them is a bit murky. So specifically I wonder if, for 5.1, we > > ought to make this change for Oracle12cDialect. What do y'all think? > > > > > > [1] - https://hibernate.atlassian.net/browse/HHH-10345 > > [2] - > > > http://docs.oracle.com/cd/A91202_01/901_doc/server.901/a90120/ch4_dep.htm#6690 > > > > > > > > On Mon, Oct 17, 2011 at 6:11 PM Gail Badner wrote: > > > >> There is a discussion about direct binding (fast) and stream binding > >> (slow) at [1]. I think it answers Scott's questions. Rather than > repeating > >> the info here, please take a look at the Oracle documentation ( > >> > http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#autoId18 > >> ). > >> > >> After thinking about this more, I think we should keep the Oracle > >> dialects as is. Here are my reasons: > >> - Hibernate defines the text/image types consistent with how Oracle maps > >> LONGVARCHAR/LONGVARBINARY; > >> - the bug lies with Oracle; > >> - Oracle has effectively deprecated valid SQL data types (LONGVARCHAR > and > >> LONGVARBINARY); > >> - the migration from "text" to "materialized_clob" has already been > >> documented since 3.5; "image" is a new type as of 3.6; > >> - a
Re: [hibernate-dev] JDBC warnings performance matter
If that’s effectively widespread, I think indeed we should guard this feature with an explicit property. It’s not necessarily easy to anticipate such consequences when designing things. In insight, something more explicit looks better. > On 28 Jan 2016, at 06:25, Vlad Mihalcea wrote: > > Hi, > > The guys at Plumbr wrote an article about how MySQL JDBC warnings are > handled by Hibernate: > > https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate > > I remember seeing this issue on StackOverflow too and I was curious if you > want to tweak it a little bit. > I also agree that relying on the log levels to prevent fetching warnings > might come as a surprise to many users and we should document this behavior. > > We could also have a hibernate.jdbc.log.warnings boolean property to > control whether we want to log those warnings or not. > This way, if users set the logger level to WARN, they will see the logs > generated by the framework stack and the JDBC warnings will be logged only > if this configuration property is true. > > What do you think? > > Vlad > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JDBC warnings performance matter
Is the call also expensive if there are no SQL warnings (i.e. null is returned, so no further walking is required)? It'd be my hope that drivers should be able to fetch the first warning - if any - upon statement execution without further round-trips. So getWarnings() would be cheap if no warnings exist. In that case people should IMHO actually fix the warnings instead of complaining that reporting them takes time. If it is a general perf issue also if no SQL warnings exist, +1 for having a property for opting into logging them. 2016-01-28 8:46 GMT+01:00 Emmanuel Bernard : > If that’s effectively widespread, I think indeed we should guard this feature > with an explicit property. > It’s not necessarily easy to anticipate such consequences when designing > things. > In insight, something more explicit looks better. > >> On 28 Jan 2016, at 06:25, Vlad Mihalcea wrote: >> >> Hi, >> >> The guys at Plumbr wrote an article about how MySQL JDBC warnings are >> handled by Hibernate: >> >> https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate >> >> I remember seeing this issue on StackOverflow too and I was curious if you >> want to tweak it a little bit. >> I also agree that relying on the log levels to prevent fetching warnings >> might come as a surprise to many users and we should document this behavior. >> >> We could also have a hibernate.jdbc.log.warnings boolean property to >> control whether we want to log those warnings or not. >> This way, if users set the logger level to WARN, they will see the logs >> generated by the framework stack and the JDBC warnings will be logged only >> if this configuration property is true. >> >> What do you think? >> >> Vlad >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
