Hibernate ORM - next steps
by Steve Ebersole
Now that 5.0 is settling down I wanted to start planning where we go from
here in terms of feature development and schedule/releases.
Here is my high-level list of features/work:
* rework SQL generation & HQL parser
* change JDBC extraction to work by position, rather than alias (reworking
SQL generation is a prerequisite)
* rework annotation binding (Jandex, etc)
* extended orm.xml, deprecate hbm.xml
* discriminator-based multi-tenancy
* port Hibernate Criteria constructs to JPA criteria, begin deprecation of
Hibernate Criteria
* extend JPA criteria API with fluent support
* ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
* merging hibernate-entitymanager into hibernate-core
* continue to fill out bytecode enhancement capabilities
Some of these are more involved than others. The task for re-writing SQL
generation is a HUGE undertaking, but also has many huge benefits.
Re-writing annotation binding is another huge undertaking, but again with
many benefits.
Any others we should add to the list here?
And then we can work on scheduling them.
10 years, 11 months
Hibernate Search for Hibernate 5 - status
by Sanne Grinovero
I'm concerned about seeing issues like this one being reported:
- https://hibernate.atlassian.net/browse/HHH-9832
I don't think it's acceptable we withhold an Hibernate 5 compatible
version of Hibernate Search for much longer.
I have a working branch of Hibernate Search "on hold" since a while
which is compiling and passing all tests successfully up to the point
of WildFly integration tests, as I could not find a way yet to run the
tests using modules and override the Hibernate ORM version (see the
wildfly-dev mailing list for details).
It was not viable either to keep this Hibernate Search branch
backwards compatible with the Hibernate ORM version 4.3 as included in
available WildFly releases.
Also since I was focusing on the WildFly roadblock so far, the branch
still needs a bit of work, for example I didn't face the OSGi tests
yet.
The "theme" for current development branch - Hibernate Search 5.3 - so
far was about the great new faceting improvements. As I discussed with
Hardy, we'd like to polish that branch for a release, so include only
necessary wrap up and fixing any reported regression, but focus
aggressively already on a new minor branch so that we could release an
ORM5 compatible Alpha in short time.
We could even consider working on a 5.3 and 5.4 in parallel.
Would you all be ok in a quick release - probably named 5.4.0.Alpha1 -
of Hibernate Search to be compatible with ORM5 and omit publishing the
modules for WildFly? That would be useful for WildFly 10 too, so they
can include the new libraries and ORM 5, breaking the cycle.
As a next step we'll see also about breaking those cycles permanently;
e.g. Hardy suggested to release modules and feature packs for WildFly
as an independent cycle, and I like that although we can keep that
decision for a post 5.4.
Thanks,
Sanne
10 years, 12 months
Re: [hibernate-dev] HSearch + Tika bridge using Wildfly modules
by Sanne Grinovero
Hi Brett,
we don't include all existing analysers and extensions within the
WildFly modules. In particular the Apache Tika libraries have a huge
amount of dependencies, you should choose the ones you need depending
on what kind of media you intend to parse.
Include any extension in your "application", we use the Hibernate ORM
classloader to lookup for extensions so these should be discoverable
if they are visible to the same classloader having your entities and
other extensions.
Sanne
On 29 May 2015 at 15:28, Brett Meyer <brmeyer(a)redhat.com> wrote:
> Hey Sanne! Artificer has '<module name="org.hibernate.search.orm" services="export" />' defined in its jboss-deployment-structure dependencies. But, when we try to use it, the following happens.
>
> Caused by: java.lang.ClassNotFoundException: org.apache.tika.parser.Parser from [Module "org.hibernate.search.engine:main" from local module loader @6cf76647 (finder: local module finder @665bf734 (roots: /home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules,/home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules/system/layers/base))]
>
> One of our entities uses the built-in TikaBridge. I figured the search.orm module would bring the necessary Tika jars in with it. Is there something else we need to add?
11 years
Changelog file in Hibernate ORM
by Sanne Grinovero
The file changelog.txt in the root ot the Hibernate ORM project seems outdated.
Is it not maintained anymore? I found it handy.
Sanne
11 years
hibernate-osgi JPA bootstrap & classloader
by Steve Ebersole
Brett,
As part of HHH-7527 (Enterprise OSGi support) you had changed
the org.hibernate.jpa.boot.spi.Bootstrap contract to basically overload
each method to additional accept a "providedClassLoader".
Every one of those methods however, also accepts
a org.hibernate.jpa.boot.spi.PersistenceUnitDescriptor which exposes 2
ClassLoader already.
Additionally, this ClassLoader is ultimately just used to build the
ClassLoaderService which hibernate-osgi overrides anyway.
Just curious if I missed something. Unless I did, it seems to me that we
really do not need these overloads on Bootstrap to support Enterprise
OSGi. This dove-tails with a discussion from the Karaf user list
ultimately discussing OsgiClassLoaderService and "holding bundles" that are
being re-installed or upgraded. Ultimately I am thinking through ways to
support being able to release OSGI bundle references from the
OsgiClassLoaderService...
11 years
Release announcements
by Steve Ebersole
At the moment we write release announcements using in.relation.to and then
announce in other mediums by posting that link. We all agree (more or
less) that the wiki editor and rendering on there leaves much to be desired.
Brett had mentioned a long time ago about GitHub and its release
capabilities and tonight I went back and looked at them again. I created a
more descriptive release announcement in GitHub then its default of just
using the tag message for this 5.0.0.CR1 release just to see how it worked
out. Here are the 2 links for comparison:
* http://in.relation.to/Bloggers/HibernateORM500CR1Release
* https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR1
There are a few things to notice here. First, I think we can all agree
that the second looks considerably better. Also, there is a lot to be said
for these being closely available from the source repo.
Another thing to note is that the GitHub release has the ability to attach
random zips and tgz. I have not taken advantage of that as I felt bad
uploading our 62 and 97 Mb release bundles here just for a PoC. I do have
a task for myself post 5.0 to re-think how we build these release
bundles[1]. But ultimately whether it makes sens to attach them here comes
down to whether we think SF and its FRS has any advantage. I think
download statistics will be the only discussion point there.
Anyway, moving forward I plan to move to this approach for release
announcements.
The only sticky point is the sourcing for the banners on hibernate.org.
What drives that? RSS?
Thoughts?
[1] https://hibernate.atlassian.net/browse/HHH-9828
11 years
HCANN, AnnotationFactory and TCCL
by Steve Ebersole
WildFly consuming ORM 5.0 is still hitting one last TCCL issue with HCANN.
It happens in
the org.hibernate.annotations.common.annotationfactory.AnnotationFactory#create
method trying to build the "annotation proxy class".
There are a few possible approaches to resolve this...
The simplest potentially effects other HCANN consumers, so we'd obviously
all need to agree. Anyway, the simplest approach is to use the ClassLoader
for annotation @interface Class rather than the TCCL. I do not see a
problem with that, but it would change some semantic.
The only other workable approach (without redesign of HCANN) I could think
of is to basically make a copy of AnnotationFactory and copy it into ORM.
Sure I could overload AnnotationFactory#create to optionally accept a
ClassLoader, but that introduces a hard dependency on new specific version
of HCANN.
Open to other suggestions. Thoughts?
11 years
ORM and database testing
by Steve Ebersole
Now that CR1 is out one of my tasks is to start setting up the database
specific jobs on CI. Initially I will just work with MySQL and PostrgeSQL
(and maybe HSQLDB).
Part of this will be auditing how we do database testing (matrix plugin)
and what does/doesn't work there. I definitely like the idea of "database
profiles". Overall I am not sure that dynamically generating tasks
specific to each database profile was a great idea. It was predicated on
the idea that I might want to run tests against all database profiles. But
that simply has not been the case in practice to date. I have to look
again at the complexity the actual matrix stuff adds. If it is a lot of
complexity I might just remove that part and have this be driven by a
single build parameter (`gradle test -PdbProfile=mysql`, e.g.).
I'd also like to look at specific hooks for the profiles in terms of
pre-/post-events at the suite, class and test levels. For example, we
might have the H2 profile set up pre-post hooks for the suite to manage the
database rather than each test building one itself. This would have a lot
of benefits. Presumably it would help speed up the build some. It would
also work more closely to non-in-memory test builds and possibly help shake
out test problems in regards to db-object conflicts earlier. Also, in
general we might decide to hook in after each class to drop schemas
(ultimately HHH-8451 is a better solution to both of these I think).
Anything else to consider here?
11 years