HSEARCH-2358 "fields" attribute in Elasticsearch search results is being ignored
by Yoann Rodiere
Hi,
I wanted to start a discussion about this issue.
It's about stored field retrieval. When searching, Elasticsearch can return
field values two different ways:
* through the "_source" attribute [1], which basically provides a
copy-paste of the JSON that was submitted when indexing
* or through the "fields" attribute [2], which only works for stored
fields and provides the actual value that Elasticsearch stored
The main difference really boils down to formatting. With the "_source"
attribute, there's no formatting involved, you get exactly what was
originally submitted. With the "fields" attribute, the value is formatted
according to the first format in the mapping's format list [3].
The thing is, Elasticsearch allows admins to set multiple formats for a
given field. This won't change the output format, but will allow using any
one of these formats when submitting information. Since these "extra"
formats probably aren't understood by Hibernate Search, this means that
using the "_source" attribute to retrieve field values becomes unreliable
as soon as someone else adds/changes documents in Elasticsearch...
So we have two solutions:
1. Either we only use the "fields" attribute to retrieve field values, and
we force users to have the output format set to something HSearch will
understand, but allow extra input formats.
2. or we use the "_source" attribute to retrieve field values, and then we
force both output and input format on users, and do not allow extra formats.
I'd be in favor of 1, which seems more rational to me. It only has one
downside: if we go on with this approach, Calendar values (and
ZonedDateTime, ZonedTime, etc.) will have to be stored as String, not as
Date, since Elasticsearch doesn't store the timezone, just the UTC
timestamp. We're currently working this around by inspecting the "_source",
which contains the original timezone (since it's just the raw, originally
submitted JSON).
What do you think?
[1]
https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-s...
[2]
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-re...
[3]
https://www.elastic.co/guide/en/elasticsearch/reference/2.4/mapping-date-...
Yoann Rodière <yoann(a)hibernate.org>
Hibernate NoORM Team
9 years, 12 months
NativeQuery and parameters
by Steve Ebersole
In the interest of questioning everything, just to make sure we are all on
the same page, Hibernate's support for native SQL queries currently
recognizes named parameters, positional parameters as well as JDBC-style
parameters.
JPA only defines support for "JDBC-style parameters" as valid for native
SQL queries:
{quote}
It is assumed that for native queries the parameters themselves use the SQL
syntax (i.e., “?”, rather than “?1”).
{quote}
Furthermore Hibernate does not support a native query using both positional
parameters and JDBC-style parameters in the same query because it causes a
non-determinism wrt the positions.
I assume we want to continue to support that full complement of parameter
types, with the positional/JDBC-style caveat.
Further I assume we will hook up the use of any non-JDBC-style parameters
in with the "strict JPA compliance" checking and throw an error when
indicated.
Anyone have objections to any of that?
10 years
HHH-9329
by Christian Beikov
Hey again,
I implemented the approach that I proposed in the issue and a test in
https://github.com/hibernate/hibernate-orm/pull/1561
It detects left joins with join tables that use the target table alias.
The join table is replaced with a subquery and the WITH clause is moved
to the join of the subquery.
Any comments?
Regards,
Christian
10 years
JPA Jira project
by Steve Ebersole
I propose that we limit who has the ability to create issues in the
Hibernate Jira JPA project.
Users routinely create issues there incorrectly, rather than the ORM (HHH)
project.
10 years
Limited history in HipChat
by Gunnar Morling
Steve, all,
Is there any way we can get HipChat Plus licenses for the team from
Atlassian?
The free client provides access only to a limited part of the chat history,
making it impossible to search for discussions discussed more than a few
weeks ago.
That's starting to be a real problem now that we've been using HipChat for
a while and early discussions begin to fall below the threshold of being
available in the free version.
I don't know whom to reach out to at Atlassian, otherwise I'd do it myself.
I'd hope they are supportive given that we can use JIRA at all for free,
too.
Thanks,
--Gunnar
10 years
Build time downloads of ORM itself during an ORM clean build?
by Sanne Grinovero
Hi all,
I just happened to build Hibernate ORM's latest "master" on a clean
machine and this is how the build log looks like:
No compatible daemons found:
- an idle daemon with different JVM constraints can't run this build
Starting a new Gradle Daemon for this build: subsequent builds will be faster
:buildSrc:clean UP-TO-DATE
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes
:buildSrc:jar
:buildSrc:assemble
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build
Download http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hib...
[...]
I'm not having any specific failure, but it seems very suspicious that
the build is needing to download hibernate-core at the very beginning
of the build?
I'm not familiar enough with ORM's build scripts to investigate myself
but I suspect some dependency order needs to be cleaned up, or you
might be including some side-effects from previous builds.
Thanks,
Sanne
10 years
Cannot build branch 5.1
by Petar Tahchiev
Hi guys,
I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal" but
I get the following error:
:hibernate-ehcache:generatePomFileForMavenJavaPublication
:hibernate-ehcache:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Starting AnimalSniffer checks using [java16-1.0.signature] against
[sourceSets.main]
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference:
net.sf.ehcache.config.TerracottaConfiguration.ValueMode[]
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.values()
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference:
net.sf.ehcache.config.TerracottaConfiguration.ValueMode
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.IDENTITY
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference: int
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference:
net.sf.ehcache.config.TerracottaConfiguration.ValueMode
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.SERIALIZATION
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference: int
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
:hibernate-ehcache:compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':hibernate-ehcache:compileJava'.
> Signature errors found for SourceSet main against java16-1.0.signature.
Verify errors and ignore them with the proper annotation if needed.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.
BUILD FAILED
Total time: 23.979 secs
Can you please help me?
--
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
10 years
AvailableSettings.DISCARD_PC_ON_CLOSE and Transaction status
by Vlad Mihalcea
Hi,
While reviewing and adding a test case for
https://hibernate.atlassian.net/browse/HHH-11120,
I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
property,
the database connection gets closed when the EntityManager is closed, while
the EntityTransaction status remains ACTIVE.
I noticed that in the call:
currentHibernateTransaction.invalidate();
But this method is no-op and deprecated as well.
Is this behavior intended? If the database connection was closed, at least
for RESOURCE_LOCAL, on most RDBMS engines, the underlying transaction gets
rolled back as well.
For JTA, the connection might still be open and allocated to the current
user since the TM controls when the resources are to be released.
Should we leave this behavior like that?
Vlad
10 years
