JPA callbacks enabled on SessionFactory
by Steve Ebersole
I recently have seen a bunch of attempts (and questions about) using JPA
callbacks with SessionFactory. At the moment, a user would need to
manually enable the proper event listeners to get this to work. I am
thinking about enabling this "out of the box". Wanted to get everyone's
opinion. I am thinking of this for post-5.0 (5.1 maybe).
11 years, 2 months
Immutable entities read-only caching improvement proposal
by Mihalcea Vlad
Hi guys,
Taking this comment as a starting point
http://vladmihalcea.com/2015/04/27/how-does-hibernate-read_only-cacheconc...
To reduce cache entities hydration, we could simply use the: "hibernate.cache.use_reference_entries" setting, but that's too restrictive
as the AbstractEntityPersister prevents it when there are one-to-many associations on an immutable entity:
public boolean canUseReferenceCacheEntries() {
// todo : should really validate that the cache access type is read-only
if ( ! factory.getSettings().isDirectReferenceCacheEntriesEnabled() ) {
return false;
}
// for now, limit this to just entities that:
// 1) are immutable
if ( entityMetamodel.isMutable() ) {
return false;
}
// 2) have no associations. Eventually we want to be a little more lenient with associations.
for ( Type type : getSubclassPropertyTypeClosure() ) {
if ( type.isAssociationType() ) {
return false;
}
}
return true;
}
If the entity is immutable and all to-many associations are all marked with "@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_ONLY)"
we could allow the entity graph to be saved as an object reference.
This way we can save a lot of unnecessary CPU processing, spent with hydrating each second-level cache entry.
Vlad
11 years, 2 months
Fwd: [wildfly-dev] WildFly 9.0.0.CR1 is released!
by Emmanuel Bernard
Some info on Jandex 2.0 move on the WildFly front.
> Begin forwarded message:
>
> From: Tomaž Cerar <tomaz.cerar(a)gmail.com>
> Subject: Re: [wildfly-dev] WildFly 9.0.0.CR1 is released!
> Date: 4 May 2015 12:30:06 CEST
> To: Jozef Hartinger <jharting(a)redhat.com>, Jason Greene <jason.greene(a)redhat.com>, WildFly Dev <wildfly-dev(a)lists.jboss.org>
>
> Yes!
>
> With 10 we are moving to java 8 which will also bring in/allow us to move to jandex 2
>
> Tomaz
>
> Sent from my Phone
> From: Jozef Hartinger <mailto:jharting@redhat.com>
> Sent: 4.5.2015 12:26
> To: Jason Greene <mailto:jason.greene@redhat.com>; WildFly Dev <mailto:wildfly-dev@lists.jboss.org>
> Subject: Re: [wildfly-dev] WildFly 9.0.0.CR1 is released!
>
> Congrats on the release!
>
> It seems that Jandex upgrade to 2.0 has not been done yet. Is my
> understanding correct that it has been postponed till WF10?
>
> On 05/01/2015 10:38 PM, Jason Greene wrote:
> > Hello Everyone,
> >
> > I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8’s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution.
> >
> > For more details, check out the release notes:
> > https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes
> >
> > As always, you can download it here:
> > http://wildfly.org/downloads/
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> >
> > _______________________________________________
> > 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
11 years, 2 months
[!] Changing the Faceting API in Hibernate Search
by Sanne Grinovero
Hi all,
Hardy completed the Faceting re-work in Hibernate Search to use the
much improved implementation from recent versions of Lucene, and we'd
like to merge his work now making these improvements available to
users of Hibernate Search 5.2.0+
There is a catch: while the API to create a Faceting Query is
unchanged and nicely backwards compatible, you'll now be required to
explicitly sign up the fields which you want to be "facetable" using a
new annotation: @Facet
The default for an indexed property is that faceting is disabled, so
people already using faceting will have to adjust their mapping, and
rebuild the indexes accordingly.
Unfortunately you won't notice the problem at compile time - and we
can't validate for it at boot time - but you'll get a reasonable
explanation in the exception when attempting to create a faceting
query.
There are many benefits to the new approach, so please bear with me
for applying such a non-backwards compatible patch in a minor release:
we won't break this rule often, nor are we lacking great reasons to
proceed.
For details see:
- https://github.com/hibernate/hibernate-search/pull/821
Thanks,
Sanne
11 years, 2 months
Multitenancy Per Schema Fails With NPE
by amit shah
I'm using schema based multi-tenancy providing implementations for both
MultiTenantConnectionProvider & CurrentTenantIdentifierResolver. Trying to
get a hibernate session for a single tenant fails with an NPE.
Looking into the source code, it seems that JDBCServicesImpl initializes
the connectionProvider to null in the else block
private JdbcConnectionAccess buildJdbcConnectionAccess(Map configValues) {
final MultiTenancyStrategy multiTenancyStrategy =
MultiTenancyStrategy.determineMultiTenancyStrategy( configValues );
if ( MultiTenancyStrategy.NONE == multiTenancyStrategy ) {
connectionProvider = serviceRegistry.getService( ConnectionProvider.class );
return new ConnectionProviderJdbcConnectionAccess( connectionProvider );
}
else {
connectionProvider = null;
final MultiTenantConnectionProvider multiTenantConnectionProvider =
serviceRegistry.getService( MultiTenantConnectionProvider.class );
return new MultiTenantConnectionProviderJdbcConnectionAccess(
multiTenantConnectionProvider );
}
}
Please find the test case attached to the mail. I have also logged an issue
<https://hibernate.atlassian.net/browse/HHH-9740>since it's blocking. Is
there something basic that I am missing.
Thanks,
Amit.
11 years, 2 months
Google Summer of Code 2015
by Martin Braun
Hi there,
I am happy to announce that I will be participating in this years Google Summer of Code working on Hibernate Search.
My project's goal is to make Hibernate Search able to work with other JPA implementors than Hibernate ORM. I have written
a short introduction about me and the project on my blog:
http://hibernatesearchandjpa.blogspot.de/
I am really looking forward to working with you all and please let me know about your thoughts on this project! :)
mfg
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
11 years, 2 months
Auto quoting of keywords used as identifiers
by Steve Ebersole
Gail, I saw your ping on IRC and thought it made sense to address here,
since you were not around on IRC anymore.
Overall, starting with 5.0, the idea is for Hibernate to automatically
quote any identifiers is recognizes as a keyword. This is all encapsulated
within the org.hibernate.engine.jdbc.env.spi.IdentifierHelper obtained
via org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#getIdentifierHelper.
There are 2 parts to this...
First, we need to be able to recognize that an identifier is in fact a
keyword. This piece is handled through
org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#isReservedWord, which is
based on a Set of keywords computed from 2 distinct "keyword sources":
1) Dialect#getKeywords
2) DatabaseMetaData#getSQLKeywords
At the moment, I think this misses a third source... ANSI SQL 2003 standard
keywords. DatabaseMetaData#getSQLKeywords specifically is supposed to
return only keywords beyond the standard (2003) defined ones. There are
really 2 options to address this:
1) add these standard keywords to Dialect
2) use a seperate (static) source for them.
Personally I prefer the second. Even if we added all the standard keywords
to the base Dialect Set, it is just too easy for the Dialect subclass to
override getKeywords(). Also, I like the idea of continuing the convention
of these other 2 sources simply returning "extras".
Second, and this is BY FAR the harder part, we need to make sure that
everywhere that is building identifiers is using this code. I tried hard
to make sure that was the case, but we all know that annotation binding is
a mess and its just too easy to miss stuff in there. I'm all happy for a
second (or third, or fourth, ...) pair of eyes looking over this part, but
I personally think it is not the best allocation of our time considering
the difficulty in actually finding them all just by code review and the
time it would take and the amount of other stuff we have to do. Eventually
we will get bug reports of cases where this does not happen. My $.02
11 years, 2 months
