[hibernate-dev] Tuned Elasticsearch docker image for development / testing / demoing
Hi, out of desperation for my laptop taking ages to run Hibernate Search / Elasticsearch tests, I created a new Docker image which improves my build times from 40 minutes to 5 minutes: - https://hub.docker.com/r/sanne/elasticsearch-light-testing/ - https://github.com/Sanne/elasticsearch-light-testing YMMV, it's great for my old laptop but only wins me a couple of seconds on the main workstation. Start it with: docker run -ti --tmpfs /run --tmpfs=/opt/elasticsearch/volatile/data:uid=1000 --tmpfs --tmpfs=/opt/elasticsearch/volatile/logs:uid=1000 -p 9200:9200 -p 9300:9300 --name es-it sanne/elasticsearch-light-testing Run the Hibernate Search testsuite with: mvn clean install -Dtest.elasticsearch.host.provided=true -Dtest.elasticsearch.host.url=http://localhost:9200 Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Upgrade version of Hibernate - default_schema specificity
Hi Margot, thanks for the feedback. 5.1.4 introduced a new default strategy used to retrieve JDBC Metadata that requires the the default_schema to be provided. In order to obtain the previous behaviour the hibernate.hbm2ddl.jdbc_metadata_extraction_strategy can be set to 'individually'. I created a new Jira https://hibernate.atlassian.net/browse/HHH-11808 Thanks again. On 7 June 2017 at 17:01, Margot PIVA wrote: > > > Hello, > > For the need of our project we had to upgrade the version of > Hibernate from 5.1.2.Final to 5.2.10.Final. > We referred to the changelog > to adapt our code and it worked perfectly well except that > Hibernate > couldn't find our schema event though it was declared on the > search_path of our PostgreSQL database > configuration (at user's level). > We observed that this behavior appeared from (and including) the version > 5.1.4.Final, > and we supposed that it came from this bugfix : > https://hibernate.atlassian.net/browse/HHH-11023 > > Finally we found out > that we had to specify the default_schema directly to Hibernate and we > thought > that it would be favourable to point this necessity out. > > > ___ > 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] HHH-11791
Now that java 8 supports named parameters it becomes possible (potentially preferrable) to use constructor injection instead of circumventing encapsulation to set values on private fields. This shows itself as a potential win when integrating with Kotlin with disallows the circumvention quite forcefully. Meaning: without constructor injection the object needs setters. And, if it has setters then it's mutable which is against best practices. I propose optionally using constructor injection when marshalling an object from data sources in a DB. I am willing to make the changes if I know they can/will be incorporated. Thoughts? Here is the ticket https://hibernate.atlassian.net/browse/HHH-11791 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-11791
Hi, Wouldn't that require all entities be compiled with? javac -parameters Vlad On Mon, Jun 12, 2017 at 10:19 PM, Christian Bongiorno < christian.bongio...@gmail.com> wrote: > Now that java 8 supports named parameters it becomes possible (potentially > preferrable) to use constructor injection instead of circumventing > encapsulation to set values on private fields. > > This shows itself as a potential win when integrating with Kotlin with > disallows the circumvention quite forcefully. Meaning: without constructor > injection the object needs setters. And, if it has setters then it's > mutable which is against best practices. > > I propose optionally using constructor injection when marshalling an object > from data sources in a DB. I am willing to make the changes if I know they > can/will be incorporated. > > Thoughts? Here is the ticket > https://hibernate.atlassian.net/browse/HHH-11791 > ___ > 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] Migration path from 3.6 to 5.2
Hi, We have been using hibernate-orm in our application for a long time. The version of hibernate we use is 3.6.10.Final. I know it is archaic. We would like to migrate to the latest stable version (5.2) to reap the benefits of new optimizations and features. Initially we thought about upgrading to 4.x. Since we are also doing Java 8 and Spring 4 upgrades, we have decided that it would be better to migrate hibernate to 5.2 together. I know it is not possible to migrate from 3.6 to 5.2 directly.I have checked online for migration guides. But I am bit off about which path should I take to migrate (eg. 3.6 to 4.3 to 4.5 to 5.2). Can someone help me with figuring out minimum number of migrations from 3.6 to reach 5.2? I would be grateful if you could point me to some resources ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-11791
To work, yes. This would be an optional means of injecting. I was thinking
some code like this (very very rough):
public void prep(DataSource source)
throws SQLException, NoSuchMethodException,
IllegalAccessException, InvocationTargetException,
InstantiationException {
ResultSet resultSet = source.getConnection().createStatement()
.executeQuery("select * from User where false");
ResultSetMetaData metaData = resultSet.getMetaData();
Set columnNames = new HashSet<>();
for(int i = 1; i < metaData.getColumnCount(); i++) {
columnNames.add(metaData.getColumnName(i));
}
Constructor toUse = Arrays.stream(User.class.getDeclaredConstructors())
.filter(c -> c.getParameterCount() == columnNames.size())
.filter(ctr -> Arrays.stream(ctr.getParameters()).map(Parameter::getName)
.allMatch(columnNames::contains)).findFirst().orElse(User.class.getConstructor());
Object entity = null;
if(toUse != User.class.getConstructor()) {// means we found a
matching constructor
Object[] input = new Object[toUse.getParameterCount()];
int i = 0;
for (Parameter parameter : toUse.getParameters()) {
input[i++] = resultSet.getObject(parameter.getName());
}
entity = toUse.newInstance(input);
}
else {
entity = toUse.newInstance();
}
}
One question that comes up is which data set is the master of the match?
Do we "Select the constructor that matches the ResultSet?" or "Do we
select the result set that matches the constructor?"
Another thought is to use the existing field selection logic (find
properties on the Class) and then look for the matching constructor; which
is a very common paradigm.
Finally: An annotation specifically indicating this might also be in order.
Just getting the discussion started
On Mon, Jun 12, 2017 at 1:41 PM Vlad Mihalcea
wrote:
> Hi,
>
> Wouldn't that require all entities be compiled with?
>
> javac -parameters
>
> Vlad
>
> On Mon, Jun 12, 2017 at 10:19 PM, Christian Bongiorno <
> christian.bongio...@gmail.com> wrote:
>
>> Now that java 8 supports named parameters it becomes possible (potentially
>> preferrable) to use constructor injection instead of circumventing
>> encapsulation to set values on private fields.
>>
>> This shows itself as a potential win when integrating with Kotlin with
>> disallows the circumvention quite forcefully. Meaning: without constructor
>> injection the object needs setters. And, if it has setters then it's
>> mutable which is against best practices.
>>
>> I propose optionally using constructor injection when marshalling an
>> object
>> from data sources in a DB. I am willing to make the changes if I know they
>> can/will be incorporated.
>>
>> Thoughts? Here is the ticket
>> https://hibernate.atlassian.net/browse/HHH-11791
>>
> ___
>> 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-11791
Hi,
this might work for a limited set of use cases, but what exactly are you
expecting from that approach? Performance might be a bit better, but
that's probably negligible. Apart from that, I only see "encapsulation"
or "ease of use with other languages" being your argument. Is that
correct, or are there other reasons why you think constructor injection
is a good fit here?
As soon as you have circular references between entities, you need a
hybrid approach with setters for some attributes. How would you do lazy
initialization of entities when some fields don't have a setter?
I could imagine that a constructor is annotated with a marker annotation
to make it selectable for this kind of hydration and allow the
parameters of that constructor to be annotated to bind them to entity
attributes. By default, the parameter names could be made use of to
avoid cluttering code. With that information, you can select the
constructor at boot time for entity types. After all, we know what kind
of SQL is generated, it's based on the field metadata, so no need for
the runtime overhead.
I don't know what others think, but when thinking about a possible
implementation, this seems like a real deep cut that touches many places.
Mit freundlichen Grüßen,
*Christian Beikov*
Am 12.06.2017 um 23:47 schrieb Christian Bongiorno:
> To work, yes. This would be an optional means of injecting. I was thinking
> some code like this (very very rough):
>
> public void prep(DataSource source)
> throws SQLException, NoSuchMethodException,
> IllegalAccessException, InvocationTargetException,
> InstantiationException {
>
>ResultSet resultSet = source.getConnection().createStatement()
>.executeQuery("select * from User where false");
>ResultSetMetaData metaData = resultSet.getMetaData();
>Set columnNames = new HashSet<>();
>
>for(int i = 1; i < metaData.getColumnCount(); i++) {
> columnNames.add(metaData.getColumnName(i));
>
>}
>
>Constructor toUse = Arrays.stream(User.class.getDeclaredConstructors())
>.filter(c -> c.getParameterCount() == columnNames.size())
>.filter(ctr ->
> Arrays.stream(ctr.getParameters()).map(Parameter::getName)
>
> .allMatch(columnNames::contains)).findFirst().orElse(User.class.getConstructor());
>
>Object entity = null;
>if(toUse != User.class.getConstructor()) {// means we found a
> matching constructor
> Object[] input = new Object[toUse.getParameterCount()];
> int i = 0;
> for (Parameter parameter : toUse.getParameters()) {
>input[i++] = resultSet.getObject(parameter.getName());
> }
> entity = toUse.newInstance(input);
>}
>else {
> entity = toUse.newInstance();
>}
> }
>
>
> One question that comes up is which data set is the master of the match?
>
> Do we "Select the constructor that matches the ResultSet?" or "Do we
> select the result set that matches the constructor?"
>
> Another thought is to use the existing field selection logic (find
> properties on the Class) and then look for the matching constructor; which
> is a very common paradigm.
>
> Finally: An annotation specifically indicating this might also be in order.
>
> Just getting the discussion started
>
>
> On Mon, Jun 12, 2017 at 1:41 PM Vlad Mihalcea
> wrote:
>
>> Hi,
>>
>> Wouldn't that require all entities be compiled with?
>>
>> javac -parameters
>>
>> Vlad
>>
>> On Mon, Jun 12, 2017 at 10:19 PM, Christian Bongiorno <
>> christian.bongio...@gmail.com> wrote:
>>
>>> Now that java 8 supports named parameters it becomes possible (potentially
>>> preferrable) to use constructor injection instead of circumventing
>>> encapsulation to set values on private fields.
>>>
>>> This shows itself as a potential win when integrating with Kotlin with
>>> disallows the circumvention quite forcefully. Meaning: without constructor
>>> injection the object needs setters. And, if it has setters then it's
>>> mutable which is against best practices.
>>>
>>> I propose optionally using constructor injection when marshalling an
>>> object
>>> from data sources in a DB. I am willing to make the changes if I know they
>>> can/will be incorporated.
>>>
>>> Thoughts? Here is the ticket
>>> https://hibernate.atlassian.net/browse/HHH-11791
>>>
>> ___
>>> 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
[hibernate-dev] Hibernate ORM 5.0 test failures
I just noticed that there were a couple of failures in the CI tests: http://ci.hibernate.org/view/ORM/job/hibernate-orm-5.0-h2/lastCompletedBuild/testReport/ Both failures are from timeouts due to: java.net.BindException: Address already in use (Bind failed) It passes locally for me. This sounds vaguely familiar to me. Did this happen on other branches? If so, what was the fix? Thanks! Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate ORM 5.0 test failures
This error: "unexpected exception opening server socket java.net.BindException: Address already in use (Bind failed)" I only got it when NVidia driver was stealing the Wildfly port, but that was never for CriteriaLockingTest. It's also curious why the Byteman agent tries to open a socket connection: at org.jboss.byteman.agent.TransformListener.initialize(TransformListener.java:69) On Tue, Jun 13, 2017 at 9:45 AM, Gail Badner wrote: > I just noticed that there were a couple of failures in the CI tests: > http://ci.hibernate.org/view/ORM/job/hibernate-orm-5.0-h2/ > lastCompletedBuild/testReport/ > > Both failures are from timeouts due to: > java.net.BindException: Address already in use (Bind failed) > > It passes locally for me. > > This sounds vaguely familiar to me. Did this happen on other branches? If > so, what was the fix? > > Thanks! > > Gail > ___ > 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
