When is Dialect.requiresCastingOfParametersInSelectClause applied?
by Mark Rotteveel
After a hiatus of 6 months, I have gone back to my PR for
improving/replacing the Firebird dialect. I am running into a number of
test failures which I am working through to see if they are relevant or not.
One of the test failures I am looking at is
org.hibernate.jpa.test.criteria.basic.ConcatTest.testSelectCaseWithConcat
Firebird is rather picky about parameters occurring in the
select-clause, and they will almost always need to be cast to the
necessary type (and lengths). This tests seems to generate the following
query:
select
case
when concattest0_.id is not null then (?||?)
else 'Empty'
end as col_0_0_,
trim(both ' '
from
(?||?)) as col_1_0_
from
TEST_ENTITY concattest0_
I have implemented Dialect#requiresCastingOfParametersInSelectClause()
to return true, but unfortunately for this specific test it has no effect.
The absolute minimum SQL necessary for this to work (with some caveats) is:
select
case
when 1 = 1 then (?||?)
else 'Empty'
end as col_0_0_,
trim(both ' '
from
(cast(? as varchar(256))|| cast(? as varchar(256)))) as col_1_0_
from
TEST_ENTITY concattest0_
And preferably the (?||?) in the case should have an explicit cast for
each parameter as well, as otherwise each parameter is limited to 5
characters each (setting longer values will lead to a truncation exception).
Is this something that is fixable, and if so how? Or is this one of
those things where you just have to say 'aw, too bad, let it go' (or,
maybe: do it later if it is really necessary)?
With this specific failure out of the way: what is the general rule of
thumb of handling test failures in hibernate_core for a lesser-known
dialect?
I currently have 257 test failures (and 512 ignored) with Firebird and
my new dialect. I might add that some failures seem to be generic (eg
DriverManagerRegistrationTest, StandardRefCursorSupportTest,
NoCdiAvailableTest, XmlAccessTest, FetchProfileTest, IndexTest and some
others).
--
Mark Rotteveel
8 years, 11 months
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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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
