Prepared statement for EAGER entity relations returning cursor not closed
by Levan Tsinadze
Hello everybody
I found that after migrating from 4.2.8.Final to 4.3.0.Final, if I have
several @OneToMany EAGER entity relations and select at least 500 rows I
get ORA-01000: maximum open cursors exceeded JDBC exception for Oracle
database (ojdbc 12.1.0.1)
I think problem is in
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad
method which calls (line 156, column
106) org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.release(ResultSet
resultSet, Statement statement) method and this last method closes only
passed ResultSet, not Statement.
I also found that in 4.2.7.SP1 in such case is
called org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.release(Statement
statement) which closes as ResultSet as passed Statement.
Sincerely,
Levan Tsinadze
10 years, 3 months
irc team meetings and jbott
by Steve Ebersole
We have been having a lot of trouble lately with relying on jbott to
record the team meetings on irc. A few times jbott has not been in the
room. A few times it refuses to start/end meetings.
Max, is there anything to be done to make jbott more stable?
If not, do we maybe want to look at using gitter for team meetings? We
would not be able to delineate meetings (unless they have added that
feature), but we would at least have the notes persistent.
Any other thoughts?
10 years, 3 months
Fwd: [wildfly-dev] Hibernate Bug (tables starting with "and")...
by Gunnar Morling
Hi,
Jess Sightler had sent the original mail below to wildfly-dev, but it seems
more suited here.
--Gunnar
---------- Forwarded message ----------
From: Jess Sightler <jsightle(a)redhat.com>
Date: 2014/1/20
Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")...
To: Tomaž Cerar <tomaz.cerar(a)gmail.com>
Cc: wildfly-dev(a)lists.jboss.org
I agree, but I am not on hibernate-dev, unfortunately, and this seems like
an issue that could affect a lot of people if it goes into the Wildfly
final release.
I believe that you have misunderstood the issue here. The issue is not
putting quotes around it (although I guess that might work around the bug).
The issue is that if you have a table starting with "and" (eg,
"androidvariant"), then this code will think it starts with " and" (note
the space). It will then proceed to rip off the first 4 characters, turning
your table name into "oidvariant".
Note how the code also does not do what the comment describing it says it
will do. Ie, it tries to remove " and" and "and ", but only checks for
"and" (no spaces) before doing the trimming.
----- Original Message -----
> From: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
> To: "Jess Sightler" <jsightle(a)redhat.com>
> Cc: wildfly-dev(a)lists.jboss.org
> Sent: Monday, January 20, 2014 10:28:40 AM
> Subject: Re: [wildfly-dev] Hibernate Bug (tables starting with "and")...
>
> Question would be more suitable for hibernate-dev mailing list.
> but in any case i am pretty sure your fix is wrong, given that you can
> achieve what you want different way.
>
> see
>
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mappi...
> more details.
> or even
>
http://stackoverflow.com/questions/9463240/how-to-configure-hibernate-to-...
>
> --
> tomaz
>
>
> On Mon, Jan 20, 2014 at 4:08 PM, Jess Sightler <jsightle(a)redhat.com>
wrote:
>
> > Is there any chance of getting a fix for this into the 8.0.0.Final
release?
> > https://github.com/hibernate/hibernate-orm/pull/658
> >
> > It seems to break a lot of generated queries on tables starting with
"and".
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10 years, 3 months
Migrating the Migration Guides
by Sanne Grinovero
The new website is missing the migration guides; specifically I'm
looking at Hibernate Search but since we probably want to keep a
familiar structure across the various projects, I hope to get feedback
from all.
I'd like to move the Search migration guide from the jboss.org Wiki to
ascidoc, but also it has become quite large and I think it should be
split in different pages.
I'd expect to see a "Migration" landing page for Search, beginning
with two lines of text for general advice, to then point to:
- Migrating from Hibernate Search 4.x to Hibernate Search 5.x
- Minor upgrade hints across Hibernate Search 4.x versions
- Migrating from Hibernate Search 3.x to Hibernate Search 4.x
- Minor upgrade hints across Hibernate Search 3.x versions
We probably want to suggest users to always migrate in steps of minor
versions, but skipping the micro versions.
For example if I'm updating an Hibernate Search 4.3.0.Final, I'd bump
my dependency to 4.4.2.Final as a first step, apply some changes as
suggested by the guides, run the tests, then jump again as needed.
My reasoning to suggest skip the micro versions is dual-fold:
- we're not supposed to break any API in that range anyway, so going
through the micro hops is probably a waste of time
- in case we screw up with some bug in the first release of a minor,
that would make a migration harder (failing tests) and we should be
correcting this with micro versions so the latest micro is what people
are supposed to use to avoid this bug
I guess we're all on the same page as general guidelines? I think this
sounds very familiar to us as we are used to this approach but it's
worthwhile to explain as occasional users might be used to different
conventions or have a different understanding of versions.
Could someone more familiar with the website details please structure
the base layout for this? Like if we could agree quickly on the shape
of the menu, I will then migrate the content for Search.
N.B. I have a lot to write down urgently for the migration to Search 5
guide: I think we'll be releasing a first preview next week and these
docs should be in place. If that doesn't work out I can of course
write it in the existing wiki.
Sanne
10 years, 3 months
Hibernate Search being integrated in WildFly
by Sanne Grinovero
Hello,
as you might already know by following the WildFly developer's mailing
list, most of the Hibernate Search jars and dependencies (Lucene) are
now included in the application server as modules.
This was not primarily driven by practical need of Hibernate users but
rather because of clustering needs of the application server, and also
CapeDwarf and other projects make extensive use of it.
Just a couple of small adjustments are needed to make it possible for
Hibernate users to also take advantage of it, so I'd think we should
make these adjustments to make it more useful?
This is what I'm thinking:
- The hibernate-search-orm jar is missing (an essential jar for our purposes)
-> add a module
- No additional analyzers are included
-> see how optional modules work, so that - while we won't ship all
those dependencies - it's still easy to add when you need one
- Jipijapa should help?
-> should we make Hibernate Search available to deployments
whenever Hibernate ORM is made available?
- Get it to a reasonable version: it's including 4.5.0.Alpha2 now
-> we need to release a Beta soon, any volunteer? I'm stuck on an
island with extremely slow connectivity.
- Contribute some integration tests to WildFly: there aren't any
today verifying the included modules
What shall we do about our modules distribution? I think it would be
nice to continue maintaining that, so that we can make frequent
releases and that would allow users to use a different version than
what they would get in WildFly - if they want to.
-- Sanne
10 years, 3 months
Hibernate: How to start a single test from the Hibernate test suite?
by Igor Chubin
Hallo, all!
I suppose that my question is obvious for many, but I could not
manage to find an answer on it.
Please help me.
Hibernate has its own test infrastructure, that can be used to test
Hibernate and its various dialects.
In the past, the infrastructure for a part of the Hibernate project,
but later (HHH-3508) it was moved to a separate project [1].
The infrastructure is based on JUnit (the tests) and Gradle
(automation of the test process) [2].
You can start all tests from the test suite using gradle:
gradle hibernate-core:matrix_mysql51
In this case all tests of the hibernate-core module will be
started. There are more than 4000 tests in the module.
I would like to start only some of them.
How do it do it? Is it possible to use the same testing
infrastructure, but start single tests from the testsuite?
Thank you very much for your help,
[1] https://github.com/hibernate/hibernate-matrix-testing
[2] https://github.com/hibernate/hibernate-orm/wiki/Hibernate-JUnit-Infastruc...
--
Igor Chubin
10 years, 3 months
Standalone service registry
by Karl von Randow
Hi all,
I had a conversation with Steve today on IRC about refactoring the org.hibernate.service package to make it standalone. The service registry implementation is mostly separable from Hibernate core already, and it could be useful in other applications perhaps where hibernate-core isn’t a dependency. I found myself in that exact situation, which is why I’m here.
I have done a test extraction of the service registry classes, excluding the BootServiceRegistry, ClassLoaderService and StrategySelector families. This was quite straight forward, worked well and worked with Hibernate core.
Steve suggested that the boot service registry and associated class loading functionality would be useful standalone as well. To see what that is like, I have now done a test extraction including the BootServiceRegistry, ClassLoaderService and StrategySelector families. It has worked quite well, but was definitely major.
Part of the discussion that I had with Steve this morning, and the piece that he particularly wanted to discuss here, is how to perform the extraction and where to put it:
* Is this standalone service registry its own project, separate from the hibernate-orm project. Would that make it easier to use in other projects? Or is it a hibernate-ssr module within the hibernate-orm project.
* Is it called hibernate-ssr or perhaps hibernate-serviceregistry? Perhaps the later is more appropriate especially if it’s a separate project.
I think the end result of the extraction I’ve done is pretty good, it does of course modify a number of classes across the hibernate-orm project (mostly just imports, though) so I’m wary that this may not be the best contribution to make as a newcomer! For reference, my WIP is here https://github.com/karlvr/hibernate-orm/compare/ssr
I have done it inside the hibernate-orm project to best preserve the git metadata (e.g. source file renames). The project compiles, tests pass (except for some osgi stuff I don’t yet understand!), and it appears to work when used in a large Hibernate project of mine.
The most interesting parts of migrating BootServiceRegistry et al over to the SSR is the Hibernate ORM dependencies in BootServiceRegistry - specifically Integrators. There were also Hibernate ORM specific features in StrategySelectorBuilder and ClassLoaderServiceImpl (specifically ClassLoaderHelper). I have created subclasses in hibernate-core of the implementations I moved to the SSR module, with the same class name as the original. These subclasses provide the Hibernate specific functionality.
Another interesting standalone issue is the exception hierarchy. The exceptions no longer extend from HibernateException. Perhaps it would be possible to have that class in the SSR package and core to address this.
I would be proud to contribute this change. I’m happy to make any changes, and I will definitely tidy up my commit messages to meet the contribution guidelines! Likewise I’m happy to throw away the work if it’s not the right approach. I had a pretty good fun morning anyway :-)
Best regards,
Karl
10 years, 3 months
Mass indexer and lazy initialization exceptions S03E04
by Guillaume Smet
Hi all,
It's been quite a long time since I came up with lazy initialization
problems in the mass indexer for the last time.
Unfortunately, this time, I don't see exactly how to fix this one and
I would like to ask for your advice about it.
The problem is quite simple:
I want to index the result of a method which invokes proxies along the
way. Something like:
@Field
public String getInformationWithProxy() {
return getField().getFieldWhichIsProxyfied().getValue();
}
As the fieldWhichIsProxyfied is not unproxyfied by an
objectInitializer, it doesn't have any session attached thus the lazy
initialization exception.
Note that the method is of course more complex than that and it mixes
fields from different fields and levels so we cannot use
@IndexedEmbedded.
As we use it to sort the results, we cannot put the information in
different fields either.
All in all, we're kinda stuck with this one.
Any bright idea out there?
Thanks.
--
Guillaume
10 years, 3 months
Why backports to Hibernate Search 4.4 branch?
by Sanne Grinovero
I've been asked on github's review comments why I'm still backporting
trivial fixes to the 4.4 branch;
moving the conversation to the mailing list:
We created the 4.5 branch because it was impossible to support both
ORM series 4.2 and 4.3, so a 4.5 release train was highly needed to
not prevent people to move onto WildFly and our latest ORM versions.
Still considering that JPA 2.1 is very new, I think it's fair to state
that our largest pool of users is using JPA 2.0 at present; of course
I'm not counting those on very old unmaintained versions as they are
unlikely to download a new version of Search or reported any issue
anyway.
So there still is a large interest, not least some of our very best
contributors, presently using ORM 4.2 and JPA 2.0, AND actively using,
debugging and reporting issues on Hibernate Search 4.4 (see for
example Guillaume's email of today).
Also, we have products to support for a very long term which are based
on this stable 4.4 branch: backporting occasional trivial issues makes
our maintenance capabilities better.
We don't promise that all fixes will be backported, and we'll probably
apply fixes only "as needed" by a specific request, but if there is
something which is definitely broken and so trivial to fix like [1], I
simply think it's easier to cherry-pick right away rather than
tracking some additional TODOs ;-)
It is also possible that we'll do more 4.4 releases as needed. Of
course I don't wish to spend too much of our effort on it, but if it's
an easy task, I don't see why we should deny it.
[Finally, I'm taking organizational steps to make such releases have
no impact on our time, so it's a win-win for everyone.. more news to
follow]
Cheers,
Sanne
1 - https://github.com/Sanne/hibernate-search/commit/f34a61e90b7dbec38a01f0a7...
10 years, 3 months
