Hibernate Search 5.6.0.Final and 5.7.0.CR1 released
by Yoann Rodiere
Hello,
We just released Hibernate Search 5.6.0.Final, the first stable release
featuring experimental support for Elasticsearch (2.x).
We also started the candidate release phase for Hibernate Search 5.7 by
releasing version 5.7.0.CR1, with support for ORM 5.2.7 and newer (but not
older, see the blog post).
This is the last step before 5.7 is released, so be sure to check it out so
you can share your thoughts with us before the release!
For more information, please see our blog:
http://in.relation.to/2017/01/30/hibernate-search-5-6-0-Final-and-5-7-0-CR1/
Cheers,
Yoann Rodière <yoann(a)hibernate.org>
Hibernate NoORM Team
8 years, 10 months
Re: [hibernate-dev] Hibernate Commons project
by Yoann Rodiere
On 30 January 2017 at 13:58, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
> Note that the current version of hibernate-commons-annotations is
> org.hibernate.common (without the s at the end, not org.hibernate as Yoann
> stated it).
>
You're right. Wouldn't the simplest solution be to use the same groupId
(without a "s") in our new repo?
> Moving hibernate-commons-annotations is not such a good idea IMHO:
> - it's licensed under the LGPL so it would force us to use this license (or
> relicense it or having different licenses for the submodules but they are
> all bad ideas)
>
It sure seems complicated. But relicensing from LGPL to ASL2 may not be
such a big deal, since LGPL seems stricter than ASL2.
Couldn't we simply dual-license the whole repository under ASL2/LGPL? That
way, previous users wouldn't need to be aware of the change, and new users
could choose to comply with whichever suits them best.
Or does it require to release two packages for each submodule (one for each
license)?
Anyway... there are other reasons for not wanting to move the code to
another repo, so maybe we could just focus on having consistent group IDs
and let the code live in different places and have different maven parents.
> - we would release a new version of this module each time we want to
> upgrade the theme and I don't think it would be readable for consumers of
> this preexisting artifact.
>
> The latter point is what worries me about centralizing all the utils in the
> same repo with the same lifecycle.
>
We already got through this discussion, but let's sum it up:
- With a common versioning, consuming projects will only have to take
care to use the latest version available and use it for every common
project they depend on.
- With a common versioning, consuming projects will retain the ability
to punctually use an older version for some subproject.
Sure, on the day we decide to break something, we'll have to bump the minor
or major for every "common" project, and it will give the false impression
that every such project has breaking changes. But we don't wan't to do that
often, and we'll probably won't have so many common projects anyway.
Having separate lifecycles/repos is probably cleaner, but it has its own
downsides:
- Consuming poms will be less readable and less easily updated (one
version per consumed common project).
- Releasing the common projects will be more work.
- Maintenance will be a bit harder (having multiple scattered repos to
work on).
- We'll run the risk of some common projects not being updated, in
particular the version of their dependencies. Which could be avoided, or at
least be less likely, if we centralize the dependency management in the
parent pom of the common projects.
We can leave hibernate-common-annotations where it is, since it's
pre-existing and already critical in several of our projects, so its
maintenance is pretty much guaranteed.
But that kind of splitting seems dangerous for the new common projects,
because it makes it harder to maintain them, and there will be no full-time
maintainers. So we'd better not split these common projects any further,
and give these projects a chance to get regular maintenance...
Yoann Rodière <yoann(a)hibernate.org>
Hibernate NoORM Team
8 years, 10 months
Update Jenkins plugins
by Davide D'Alto
Hi,
there are some plugins to upgrade on Jenkins and it seems they have
some non trivial changes.
I'll do that on Thursday and hopefully it won't cause too many issues.
Thanks,
Davideb
8 years, 10 months
Hibernate Commons project
by Guillaume Smet
Hi,
So, as discussed at the F2F, I set up an hibernate-commons project.
Currently, it's here https://github.com/gsmet/hibernate-commons, waiting
for everyone to agree on the name, the license, the purpose and so on.
We would like to make quick progress on it as it's blocking for the
migration of Search and OGM to the new AsciiDoctor output (we are still
using Docbook as the final output for these projects). It would be nice if
we could move them to this output for Search 5.7 and OGM 5.1 which are
planned for the coming weeks.
Basically the idea behind this repo is to centralize things useful to all
(or several) Hibernate projects:
- an AsciiDoctor theme
- testing utilities we would like to share for all the Hibernate projects
- (still to be decided as not that obvious) utilities we would like to
share for the NoORM projects
Things that should be discussed:
== The groupId
I used hibernate-commons as it seemed like an obvious groupId. The fact is
that we already have hibernate-commons-annotations here.
Thoughts?
== The license
Most of our projects are LGPL licensed except for HV which is Apache 2
licensed. Which license should we choose?
== The AsciiDoctor theme
So the theme I put in is slightly different from the one from ORM:
- the top banner is white instead of black. The black banner was a bit too
aggressive to my taste;
- I was very light on customizing the HTML output as I would really like us
to not spend time on maintaining it. So it's basically the default output
whereas ORM has customized the color of the titles of the links and several
other things. I think the default output is really nice and we can keep it
as is;
- I customized the PDF output a bit more as there were problems with the
default output. I think it's pretty good now.
Here is the current output for Search:
- HTML: http://docs.jboss.org/hibernate/beta/html_single/
- PDF:
http://docs.jboss.org/hibernate/beta/pdf/hibernate_search_reference.pdf
-> note that if you want to use a specific theme for specific purposes, it
would still be possible. It's a base you can configure with your own CSS
and such.
Thoughts?
--
Guillaume
8 years, 10 months
[HV/HSEARCH] Free form
by Emmanuel Bernard
I took the flight home to play with free form and specifically how we would retrieve data from the free form structure.
By free-form I mean non POJO but they will have schema (not expressed here).
https://github.com/emmanuelbernard/hibernate-search/commit/0bd3fbab137bda...
And in particular
https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freefor...
https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freefor...
It probably does not compile, I could not make the build work.
I figured it was important to dump this raw thinking because it will influence and will be influenced by the redesign of the DocumentBuilder of Hibernate Search.
There are several options for traversing a free form structure
- expose the traversing API as a holder to navigate all properties per structure and sub structure. This is what the prototype shows. Caching needs to be accessed via a hashmap get or other lookup. Metadata and the traversing structure will be navigated in parallel
- expose a structure that is specialized to a single property or container unwrapping aspect. The structures will be spread across and embedded in the Metadata
Another angle:
- create a traversable object per payload to carry it (sharing metadata info per type)
- have a stateless traversable object that is provided the payload for each access
The former seems better as it does not create a traversable object per object navigated.
The latter is better for payloads that need parsing or are better at sequential access since state could be cached.
We need to discuss that and know where DocumentBuilder is going to properly design this API.
Emmanuel
8 years, 10 months
Extended KEY expression support
by Christian Beikov
I have a little proposal for supporting the use of a KEY expression in
the FROM clause and I'd like to hear your opinions on that.
Unfortunately the JPA spec does not support that, but since a key of a
java.util.Map mapping may be an entity type, we need to specify how one
can "join" that key explicitly.
Right now(pre HHH-10537), when joining a java.util.Map mapping, an inner
join is generated for the map key entity type. In my fix for HHH-10537 I
changed the behavior to respect/inherit the join type of the collection
join.
The problem is, that one can't further join any attributes on that key,
because there is no syntax in the HQL or the JPA spec that allows to do
that.
We need to decide (1) whether we always want to join the entity key or
require the user to do that specifically via e.g. something like "JOIN
alias.map m JOIN KEY(m) k"
and also (2) how the syntax for joining further attributes should look
like. If we decide to not allow the "JOIN KEY(m)" syntax for (1) we have
to support something like "JOIN KEY(m).association", otherwise we can
just use the alias like for normal joins "JOIN k.association".
Either way, we have to change the grammar but I'd rather like to
support/implement the map key joining syntax like "JOIN KEY(m) k" for
(1). A further change to that would be to not generate the implicit key
table join anymore but require the user to do the join explicitly. Since
that would break backwards compatibility, I'd like to make that behavior
configurable and of course, by default it will generate the implicit key
join to maintain backwards compatibility. I also propose to switch the
default in 6.0 so that the join is not generate anymore.
The usage in the JPA Criteria API will unfortunately require a cast
since the return type of javax.persistence.metamodel.MapAttribute#key()
is javax.persistence.metamodel.Path instead of
javax.persistence.metamodel.SingularAttribute but essentially the same
functionality is available to a user out of the box.
Specifying a custom join for a key would look like this in the Criteria API
MapAttribute<Entity, MapKeyEntity, MapValueEntity> mapAttribute = ...
Join<Entity, MapKeyEntity> keyEntity =
mapAttribute.join((SingularAttribute<? super Entity, ? extends
MapKeyEntity>) mapAttribute.key(), JoinType.LEFT);
keyEntity.join(...)
So the questions again.
1. Do you all agree that this is important and should be done?
2. Agree to not generate implicit joins for keys in future versions?
3. Allow joining the key in a separate join?
4. Allow further joins on a key?
5. Happy with how it can be done in JPA Criteria?
In addition to that, it would be nice if anyone could make someone from
the JPA EG aware of this.
From a JPQL BNF point of view, I'd propose the following changes
from
join_single_valued_path_expression::=
identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field
to
join_single_valued_path_expression::=
identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field
|
map_field_identification_variable
Regards,
Christian
8 years, 10 months
boolean type support
by Steve Ebersole
Another thing we run into in 6.0 dev is handling booleans, specifically in
regards to dealing with the database representation (0 or 1, versus 'T' of
'F', versus ...).
The way we handle this today (pre-6.0) is to "fake it" by registering a
JavaTypeDescriptor for each representation combo[1]. We can obviously
continue to do it this way.
But in moving forward we wanted to take a step back and look at this
again. And really this is the kind of scenario that AttributeConverters
are designed to handle. So we are considering to instead actually handle
this via an AttributeConverter. To fully understand this remember that we
have also moved AttributeConverter tracking on to the attribute[2] itself
as opposed to "baking it" into a Type. In that way it would just be
handled by the "type system" to automatically add an AttributeConverter to
the attribute.
Obviously that only works if there is not already an AttributeConverter
applied to to the attribute. I cannot imagine that ever happens in a
supported way, or a way that we want to support. Essentially that would
mean a condition where we convert the value twice in each direction. But
in case we miss some ase, I wanted to ask the list.
[1] Yes, it seems odd that this is handled in the JavaTypeDescriptor. The
reason it happens that way is that it is incorporated into the wrap/unwrap
code.
[2] I say "attribute" just a a means of simplification. It is really a
Navigable which is new concept and probably not well known to everyone..
8 years, 10 months
6.0 - ResultTransformer
by Steve Ebersole
Another legacy concept I'd like to revisit as we move to 6.0 is the
Hibernate ResultTransformer. I'd argue that ResultTransformer is no longer
needed, especially in it's current form.
Specifically, ResultTransformer defines 2 distinct ways to transform the
results of a query:
1. `#transformTuple` - this method operates on each "row" of the result,
allowing the user to transform the Object[] into some other structure.
This is specifically the one I see no value in moving forward. Between
dynamic-instantiation, Tuple-handling, etc I think users have the needed
capabilities to transform the query result tuples.
2. `#transformList` - this one operates on the query result as a whole
(unless scroll/iterate are used). This method at least adds something that
cannot be done in another way. But I'd still personally question its
overall usefulness.
Does anyone have an argument for continuing to support either of these?
Personally, I propose just dropping the ResultTransformer support
altogether.
8 years, 10 months
Example of WildFly JPA container safely closing the EntityManager after the application calls transaction.rollback, which also handles background tx reaper thread time outs
by Scott Marlow
Hi,
[1] is an example of how the WildFly JPA container is ensuring that
the background (transaction manager) reaper (transaction timeout)
thread does not cause EntityManager.close() to be called, while the
application is actively executing calls to EntityManager.*().
The idea, as suggested by Tom Jenkinson, is to track when the
application (container) calls transaction.commit/rollback. We also
register a Synchronization. When we detect that
transaction.commit/rollback and the Synchronization.afterCompletion
have both been called, it is safe to perform the EntityManager clean
up action, as we know that only one thread will then be invoking the
EntityManager.close().
>From a state point of view, please look at how [2] is checking for the
EventType.DISASSOCIATING event, which means that
transaction.rollback/commit was called by the application. If the
Synchronization.afterCompletion has already run as well, then we clean
up the EntityManager, otherwise, we defer the cleanup action until the
call to Synchronization.afterCompletion occurs.
Also see [3] which contains the recommendation of using the above solution.
Scott
[1] https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...
[2] https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...
[3] https://developer.jboss.org/message/919807
8 years, 11 months
6.0 - Type system
by Steve Ebersole
We are getting pretty far along on the 6.0 changes and I wanted to start
a(nother) discussion about Types in 6.0 to get feedback and thoughts on a
few topics.
First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types
and "persisters"...
(a lot of this is the same from pre-6.0, just making things more explicit)
JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so let's
start there. A JavaTypeDescriptor is a descriptor of a given Java type.
That is, it provides Hibernate with information about the Java type. Is it
a numeric type? How do we compare 2 values of this type? How do we make a
deep copy of a value of this type? Etc. SqlTypeDescriptor is the same,
but for a database type (VARCHAR, BLOB, etc). These 2 work together to
perform reading and writing at the JDBC-level.
We decided to broadly categorize JavaTypeDescriptors based on the JPA type
categorizations:
1. BASIC - BasicJavaDescriptor
1. TemporalJavaDescriptor
2. NumericJavaDescriptor
2. MANAGED - ManagedJavaDescriptor
1. EMBEDDABLE - EmbeddableJavaDescriptor
2. IDENTIFIABLE - IdentifiableJavaDescriptor
1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor
2. ENTITY - EntityJavaDescriptor
Type (org.hibernate.type.spi.Type) represents a combination of a
JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a
specific "non-root Navigable domain value". Navigable is a query-focused
contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a
high-level t is similar to JPA's Bindable except that it applies to
Collection indices (or map-keys) and elements (or map-values) as well.
Navigable essentially represents an named navigation one can perform in a
query. The root Navigable is always an entity (EntityPersister).
EntityPersister is the only Navigable that does not expose a Type. (There
is an EntityType, but it represents entity-valued non-root Navigables such
as a ManyToOne). All other navigables expose a Type. That is all a
long-winded way to say that Types represents that Java/SqlTypeDescriptors
for a role-based Navigable.
Like the categorization discussed above for JavaTypeDescriptor, Type has a
similar categorization:
1. Type
1. BasicType
1. TemporalType
2. AnyType
3. ManagedType
1. EmbeddedType
2. IdentifiableType
1. MappedSuperclassType
2. EntityType
It is important to keep in mind that these represents a specific reference
to thse things in regards to a Navigable. E.g. an EntityType is the "type"
of a SingularPersistentAttribute that is a ManyToOne - it points to the
corresponding EntityPersister but it also represents the FK columns to
refer to the entity. It is a role-based Navigable.
Historically reads and writes have all routed through the Type (with
certain Types delegating much of that to persisters). That will no longer
be the case in 6.0 as one of the main design goals for 6.0 is to re-write
how Hibernate reads and writes (mainly reads) values from JDBC. The major
shift here is to read all values from JDBC using a "SqlSelectionReader"
equivalent to a BasicType. These values are read and held in an array that
"readers" then know how to access (positionally) and use. Most of that
design is beyond the discussion here, but it useful to understand. It is
discussed in the design.adoc in my orm-sqm poc repo for those curious.
Long story, short... Types no longer directly implement JDBC read/write
which we will come back to later.
PersistentAttribute and the other Navigables now take a role in JDBC
reads/writes. AttributeConverters and other read/write-related concerns
have been moved to these contracts. Again, most of this is covered in the
mentioned design doc.
Since Type no longer directly implements JDBC read/write operations I think
it is important to ask ourselves what exactly we see as "customizable" wrt
each Type. Is that different for each category, or the same across all
Type categories? E.g. I know of no customization of EntityType as it
exists in 5.x, and tbh I am not even sure what that would mean. BasicType
obviously has some parts that we want to allow users to override, but is
that really best achieved through a custom BasicType? Or is it better
served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or
SqlSelectionReader? What about EmbeddedType? CollectionType? This would
affect @TypeDef and Type registration methods specific to customizations.
Persisters for the most part continue to serve the same role they have in
the past with a few additions and some changes...
One addition was the creation of an EmbeddedPersister. *Embedded*. This,
like CollectionPersister, models a "role" e.g. "Person.name" as opposed to
the Embeddable Name.class. Note however that JPA calls it an
EmbeddableType and expects info about the Embeddable (the Class).
EmbeddedPersister is role-based (Embedded) instead, which is a mismatch.
In the case there are more than 1 usage of the Embeddable in different
Embedded roles then we have to decide which EmbeddedPersister to return.
It affects the sub-Attributes information. We could just return "one of
them" and deal with it for Alpha1, but we should answer what we want to do
there long term.
Collectively, these persisters now implement the JPA ManagedType model
directly. Another addition was the creation of ManagedTypeImplementor,
IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the
persister hierarchy. Which means we can now directly return them in our
JPA Metamodel impl.
That also means implementing JPA's notion of Attributes. I also needed
something similar for SQM's Navigable contract. Plus I have been working
towards changing how Hibernate understands Attributes internally
(encapsulation - OO ftw!) for some time anyway, so this all dove-tailed
well.
There are some things we should discuss too in terms of user impact. We
know up front that we need to move to reading values from JDBC ResultSets
positionally, as opposed to nominally which is how it was exposed in
Hibernate prior to 6.0. So we know already we will be asking implementors
and consumers of those contracts to make changes. Given that, we have
*some* liberty in changing these contracts some more. We just want to be
cognizant of (a) how much we change, (b) who it affects (use cases) and (c)
whether there are alternatives. For any use cases we determine to be
"valid" use cases, I think we need to make certain that there is some way
to handle that in the new alternatives.
One use case, e.g., is setting Query parameters and being able to specify
its Type. To a degree we want to be able to continue to support that. But
I think we limit it to just references to org.hibernate.type.Type (though
"gutted") specifically and remove all others; and temporarily have the new
org.hibernate.type.spi.Type interface extend the old. This would allow
them to continue to get these org.hibernate.type.Type references in some
fashion and use them as Query parameter type hints. But I think we should
look at implementing some other parameter type "hints" like accepting
PersistentAttribute/Navigable references, JPA (static) metamodel
references, etc. These are better, as they would include things like
AttributeConverter whereas the Type reference would not.
Sorry this got so long. I've had a lot floating around in my head the last
few days as I have worked on 6.0 and I wanted to bring them up for
discussion. The main thing I wonder about is what we mean by "custom
types" in terms of what exactly is being customized? And how does that
relate specifically to BasicType versus EmbeddedType versus ...?
8 years, 11 months
