Introducing a "none" BytecodeProvider
by Sanne Grinovero
After some experimentation I figured out that the BytecodeProvider is
not really necessary, if you are happy to use the tools we have to
enhance the entities upfront.
In some environments such as on GraalVM I need to pre-enhance the
entities (need as in "not optional"), but some further things would be
really much simpler if I then could exclude Byte Buddy from runtime
dependencies.
As the code stands today, the Byte Buddy engine is loaded very early
during bootstrap (even if the entities are already enhanced, as we
didn't test for that yet at this point) and can't be disabled.
I have a successful experiment which introduces a "none" configuration
value for the "hibernate.bytecode.provider" property which allows me
to fully disable the need to have ByteBuddy on classpath at runtime.
I would not generally recommend this as there is no safety net: if you
set this property AND did not enhance your entities, I expect trouble.
Also there's a strong limitation: I could not implement the
`BasicProxyFactory`, which is probably making this unfit for general
purpose; I could use some help to nail down why exactly we need this
and see if we can actually implement an alternative - possibly having
the build time entity enhancement tools generate the necessary
bytecode upfront?
Still, I'd propose to merge this feature as an advanced feature that
some power users will need when making progress on support for new
platforms. Because of this experimental aspect, I'm not bothering to
mention it on the user guide :)
Ok?
Thanks,
Sanne
6 years, 1 month
ORM 5.4 breaking SPIs - MetamodelImplementor
by Yoann Rodiere
Hello,
Thanks to a periodic Hibernate Search build I set up to run against
Hibernate ORM 5.4, I just noticed [1] a backward-incompatible change in ORM
5.4 [2]: mainly, the MetamodelImplementor class was moved from
org.hibernate.metamodel.spi to org.hibernate.metamodel.model.domain.spi.
While I understand that SPI changes are allowed in minor version
increments, it was my understanding that 5.4 was supposed to only bring
fixes that we are not comfortable with merging into 5.3, not new features
or improvements. Did I understand that correctly?
If so, I'd suggest to cancel this renaming, or at least restore the old
interface, deprecate it and make it a superinterface of the new one, to
restore backward compatibility. And see if other SPIs should benefit from
the same treatment.
If not, I will give up on the idea of Search 5.10 being compatible with ORM
5.4, and will plan for a 5.11. Let's hope the changes in ORM 5.4 won't
affect EAP/Spring/etc., though. I suppose if it's only SPI it should be
alright...
Steve, folks, WDYT?
[1]
http://ci.hibernate.org/blue/organizations/jenkins/hibernate-search-yoann...
[2]
https://github.com/hibernate/hibernate-orm/commit/5e8781f8fa123d4e437f669...
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
6 years, 1 month
XML access to entities
by Stephen Fikes
Is there a known / recommended solution for working with Hibernate entities as XML?
There used to be an XML based session (DOM4J) but this is no longer a part of current Hibernate versions.
Thanks!
Stephen
6 years, 1 month
Jira - edit comments
by Steve Ebersole
Did someone remove the ability to edit one's comments? I added a comment I
would like to adjust syntax (code fragment), but Jira will not let me
6 years, 1 month
Deprecating Environment#verifyProperties
by Sanne Grinovero
Currently this method is used but not doing much at all, as maps
OBSOLETE_PROPERTIES and RENAMED_PROPERTIES are constant and empty.
I'm wondering if this is because it's just a coincidence at this point
in time we have nothing registered in those maps, or if this strategy
is just no longer the preferred choice to handle "out of date
configuration properties".
I'm guessing that going forward we all rather implement such logic
using ad-hoc logic and more specific error messages?
In that case I'd want to deprecate this code and remove those maps. Objections?
Thanks,
Sanne
6 years, 1 month
CriteriaBuilder, aggregation and types
by Guillaume Smet
Hi,
We have an interesting test case here
https://hibernate.atlassian.net/browse/HHH-13001 about the use of
LiteralHandlingMode with the criteria builder. It turns out that the
problem is a bit more general than that.
Let's take this (not so useful) example:
query.multiselect(
document.get( "id" ),
cb.sum( cb.parameter( Long.class ) ) )
.groupBy( document.get( "id" ) );
It will lead to a NPE when trying to determine the return type of the sum
in:
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
The fact is that we totally lose the type information along the way.
I don't know if it's something addressed in 6 and if we should try to fix
it in 5.4. In any case, I think having a workaround would be nice.
There are a few paths we could follow:
1/ at least throw a more meaningful error and provide a workaround. I
thought about forcing the use of the cast function but it doesn't work as
we have an optimization not adding the cast function is the type is
corresponding (see
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...).
If we remove this one and provide a helpful error message, that could help.
Note that I don't know if it's just an optimization or something mandated
by the spec itself.
2/ we could try to add a cast automatically for these functions needing a
proper type only when strictly necessary e.g. when you have a parameter (or
a LiteralExpression transformed to a parameter). That would mean adding a
method ExpressionImplementor (and change all our code to use
ExpressionImplementor as it currently uses the JPA version mostly
everywhere). That would be more transparent for the user but clearly a
significant amount of (dumb) work/changes. And probably a nightmare to
merge in 6 if this area has changed.
Thoughts?
--
Guillaume
6 years, 1 month
persister.afterInitialize() called too early
by Guillaume Smet
Hi,
On Friday, I started to take a look at
https://hibernate.atlassian.net/browse/HHH-12425.
The current flow of operations is the following:
Loader#initializeEntitiesAndCollections
\_ TwoPhaseLoad.initializeEntity()
\_ initialize the entity
\_ persister.afterInitialize()
\_ endCollectionLoad of the collection persisters
\_ TwoPhaseLoad.postLoad()
The issue we have is that afterInitialize() is called before the collection
loading has been done. The collections are not in the persistence context
yet when calling persister.afterInitialize(), which is required with
enhanced entities.
As afterInitialize() is supposed to be called after the properties have
been initialized, I think it makes sense to wait for the collections to be
properly initialized.
I'm wondering if we should isolate the persister.afterInitialize() call
into a TwoPhaseLoad.afterInitialize() method, which would be called after
the collection initialization.
Any thoughts or better ideas?
Thanks.
--
Guillaume
6 years, 1 month
HCANN 5.0.5.Final released
by Sanne Grinovero
Hi all,
I tagged a 5.0.5.Final release for the sole purpose of aligning the
dependency of org.jboss.logging:jboss-logging with version 3.3.2.Final
: no other changes.
Next I'll upgrade ORM as I need this; I guess upgrading other projects
is entirely optional as there's no real benefit - except satisying
your OCD of dependency alignment :)
enjoy!
Sanne
6 years, 1 month
