People need an Hibernate Search release to match ORM 5.2
by Sanne Grinovero
Hi all,
as you might be aware, ORM 5.2 made some rather radical internal work,
and the latest Hibernate Search releases aren't compatible.
So far, business as usual: we typically simply catch up on the next minor.
The problem is that normally Hibernate Search releases are time-boxed
- with us only merging new features when they are ready - so that we
can trigger a release as needed, as contingency required.
However currently we switched temporarily to a less desirable "we ship
when it's ready" as the Elasticsearch integration couldn't possibly be
developed by a single person in a feature branch, so in short we're
not in a position to "just release" it, as it's not ready and this
will take another month (optimistically). This would position
Hibernate Search 5.6 in September.
We'd also want to have WildFly users have a chance to use this new
Elasticsearch feature, which ties us to make this release compatible
with ORM 5.0 and 5.1.
So Hibernate ORM 5.2 users who need Hibernate Search will need to wait
for Search version 5.7, which in timelines would mean this fall.. way
too far ahead.
(I tried to figure out a way to make Search master compatible with
both, but that's just not possible: it's either/or, barring an
outrageous amount of work which I'd rather spend in finishing 5.6 and
move on do do the migration properly..)
On HSEARCH-2296 [1] James proposed we could already publish a 5.7 SNAPSHOT.
Assuming we can set the right expectations, what would you think of
this idea to branch a 5.7 already even though 5.6 isn't done?
We could even call it Alpha1 and tag appropriately. The goal is of
course to make sure people have at least something they can test with
and make progress while we put our stuff together.
The downside is of course that all remaining work on 5.6 will have to
be regularly rebased and applied to 5.7 too. Considering we won't do
any other changes on 5.7 I don't expect this to hurt too much.
Thanks,
Sanne
1 - https://hibernate.atlassian.net/browse/HSEARCH-2296
8 years, 3 months
Supporting timezone in Timestamp Type
by Vlad Mihalcea
Hi,
While reviewing the Pull Request for this issue:
https://github.com/hibernate/hibernate-orm/pull/1536
I realized that we can improve the default TimestampType as follows:
1. We could make it parameterizable so that it can also take a custom
timezone (UTC) during mapping.
2. We could also define a default timezone so that we don't rely on the JVM
one. This might be desirable when the UI requires to display the time in a
certain timezone, while we want to save all timestamps in UTC.
Let me know what you think.
Vlad
8 years, 3 months
Centralized access to "bootstrap only" resources
by Steve Ebersole
We have a number of resources whose references are valid only during
bootstrap. This includes things like:
- ClassmateContext
- JPA temp ClassLoader
- Scanner and related
- HCANN ReflectionManager (eventually Jandex)
- etc
The problem is that as currently handled (via
MetadataBuilder/MetadataBuildingOptions) these resources actually are
available at runtime as well, since the MetadataBuildingOptions lives on as
part of the SessionFactory.
The idea of a "bootstrap only" ServiceRegistry has been discussed a few
times as a way to solve this. That would work, except that it would
potentially get confusing in regards to being sure we are passing the
correct ServiceRegistry all the time IMO.
Lately I started thinking of an alternative solution: splitting up
MetadataBuildingOptions
into 2 distinct contracts: one with the same idea/scope as now, and another
whose lifecycle is scoped to the bootstrap process. I am tentatively
calling this org.hibernate.boot.spi.BootstrapContext.
For the most part these changes are isolated internally. Currently I
have MetadataBuilderImpl
building both the MetadataBuildingOptions and this new BootstrapContext.
Some of the applyXYZ calls on MetadataBuilder are now directed to
BootstrapContext instead of the MetadataBuildingOptions.
MetadaBuildingContext was changed to add exposing the BootstrapContext in
addition to the MetadataBuildingOptions. For the most part this works very
well, and like I said is pretty well isolated internally. However, it does
affect any existing usages of those methods removed
from MetadataBuildingOptions. The biggest disconnect there so far is in
JpaIntegrator which tries to access the HCANN ReflectionManager during its
JpaIntegrator#integrate call to process entity callbacks/listeners. With
JPA support being integrated into hibernate-core, we could probably work
around that one by consuming that bit-of-logic into the transformation of
InFlightMetadataCollector -> MetadataImpl. IMO this is a "win" anyway as
it would allow users to leverage JPA entity callbacks/listeners in native
Hibernate apps as well; so this change would not necessarily be a "bad
thing". Another option would be to change the signature of
Integrator#integrate. To be honest it was probably always a mistake to not
use a "parameter object" to pass in to #integrate.
This also has a tie-in with the 3-phases for TypeConfiguration discussed on
HipChat. To recap, TypeConfiguration (see 6.0 type system design if
unfamiliar with TypeConfiguration) has the following "phases":
1. TypeConfiguration initialization - this is initialization of the
TypeConfiguration itself. During this phase no "context" is available to
the TypeConfiguration.
2. Metadata building - essentially this is the time spent transitioning
from MetadataSources to Metadata.
3. live SessionFactory - from the point we instantiate the
SessionFactory.
The first discussion here is exactly how to handle the period from the end
of phase 2 to the beginning of phase 3. Ideally (from an OO encapsulation
perspective) we'd end the second phase after we have built the MetadataImpl
from the InFlight variety. However that leaves a "gap" in terms of the
TypeConfiguration having any context. The other option is to carry the
BootstrapContext along into the MetadataImpl, along into the
SessionFactoryBuilder and to release the BootstrapContext and scope the
TypeConfiguration to the SessionFactory only after the SF is built. So
we'd still not carry that information in the SessionFactory, but we'd keep
it around until the SessionFactory is built. Basically this allows types
and descriptors access to the scoped context (MetadataBuildingContext here
specifically) during that small gap of transitioning from Metadata -> SF.
This is what I propose we do; just want to make sure no one has objections.
A last part I want to consider is integrations with other Hibernate
projects. Initially I spoke with Gunnar about this a lot in terms of OGM.
I think it is important that we allow the same paradigm we do now for
bootstrapping for the sake of continuity. However I do wonder if, in terms
of integrations, it might also be beneficial to allow an alternate way to
bootstrap as well. Gunnar, back when we developed this you had mentioned a
central "bootstrap delegate builder" contract. That also could fit really
nicely with these new changes. Is that something that would help OGM at
this point? Or should we stick with what we have for the sake of
continuity?
Sorry this got so long, but there is a lot of discuss here :)
8 years, 3 months
HHH-10770
by Petar Tahchiev
Hi guys,
https://hibernate.atlassian.net/browse/HHH-10770
has been fixed in Hibernate 5.2.0. However Hibernate 5.2.0 requires Java8
and there are a lot of projects out there that cannot upgrade to Java8 for
now. Also This is one of the reasons Spring-boot still relies on Hibernate
5.0.9 for example - because Spring Boot is not Java8 yet.
Do you think you can backport the JCache feature to 5.1. Otherwise we need
to wait one year until next April when Spring5 + Sprinb-boot 2.0 will come
out and support Java8.
Thank you
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
8 years, 3 months
Oracle CI machine upgrade
by Davide D'Alto
Hi,
I've upgraded the oracle instance on CI, it is now on version 12.1.0.2.v4
Cheers,
Davide
8 years, 3 months
[OGM] Bolt vs Rest for Neo4j
by Davide D'Alto
Hello,
at the moment in OGM we connect remotely using the Rest API.
The reason is that when I created the dialect the new Bolt[1] protocol
wasn't available.
I've now finished implementing the dialect so that it uses the Bolt
protocol, there is a lot of duplication since it is very similar to
the approach I used for Rest.
I worked for a while trying to improve the code but I started to
wonder if it might be really helpful to provide two ways to connect
remotely with an increase in complexity of the code (more interfaces
mainly with some additional classes).
I'm now of the idea that we could remove the dialect thata uses Rest
and only keep the one that uses Bolt (as suggested by Giulliame in an
old chat on hipchat).
This will simplify the code and we can always add it back if the need
arise or somebody asks.
Note that the Bolt protocol is the suggested one to use for Neo4j
since it promises better performance.
It will also allow us to remove some dependencies required for the rest client.
Please, let me know if you think there is value in keeping both
approaches, otherwise I'm going to send a PR that removes the remote
one.
Thanks,
Davide
[1] https://dzone.com/articles/introducing-bolt-neo4js-upcoming-binary-protoc...
8 years, 4 months
Mapping JPA's @MapKeyEnumerated and @Enumerated on native-enum supporting datastores
by Sanne Grinovero
In the context of Hibernate OGM, it turns out that some datastores
have a rather nice "native" support for enums.
We aim to map each property of the user's domain model to its most
appropriate "physical type", unless the choice is overriden by the an
explicit user request.
In the case of an Enum, JPA annotations such as @Enumerated have an
attribute EnumType to choose the physical representation:
public enum EnumType {
/** Persist enumerated type property or field as an integer. */
ORDINAL,
/** Persist enumerated type property or field as a string. */
STRING
}
However, there's no support for a "NATIVE". Also, the annotation
specifies that "ORDINAL" is the default value so I can't just assume
that the user didn't specify anything and we're good to use our own
NATIVE implementation.
Assuming that we can't change the JPA spec, any suggestion on when I
could have the Hot Rod dialect for OGM to actually produce a "nice"
mapping into native enums?
I'm tempted to just use natives all the time; In the case in which the
user opted for "STRING" I could drop a warning - or decide to honour
that - but in case of ORDINAL I just can't tell if it's a default
choice or not so I think a warning would be too much.
Another alternative would be that I "go native" when the @Enumerated
annotation isn't specified at all: looks like this mapping is valid
according to ORM as it seems to treat it as if there was an implicit
@Enumerated annotation; I'm not happy about having to rely on people
to not use an explicit annotation though.
Thanks,
Sanne
8 years, 4 months
[HV] Jumping to HV 6?
by Gunnar Morling
Hi,
Now that the first changes in HV are being made towards BV 2.0, one
question is which version of HV that should be.
For BV we are doing a major version jump from 1.1 to 2.0 as the minimum
Java version is raised. So I'm suggesting to do the same for HV and jump to
a new major, HV 6. We also may get rid of some HV-specific SPIs and replace
them with ones standardized in BV 2.0, which are breaking changes by their
nature and thus also justify the new major*.
Assuming we agree on moving to HV 6 for BV 2.0, what should happen to the
current 5.3 family? We did an Alpha of it a while ago. Just leaving it
behind like that would look very bad IMO. So I'm inclined to release a
quick CR + Final, essentially containing what has been done prior to the BV
2.0 work (plus maybe some more bug fixes). That should happen rather
quickly so we can focus on HV 6.
Also WF could get that next 5.3 to contain the latest fixes of the BV 1.1
RI.
If there are no objections to that plan, I'd move forward with it and aim
for 5.3.CR1 release some time next week.
Thanks,
--Gunnar
* ResourceBundleLocator comes to mind which would be obsolete in its
current form when splitting up the notions of message interpolation and
resource bundle retrieval
8 years, 4 months
