Batch version data support in Dialect
by Vlad Mihalcea
Hi,
While browsing the PRs on GitHub, I stumbled on this issue:
https://hibernate.atlassian.net/browse/HHH-10290
In the current implementation, the hibernate.jdbc.batch_versioned_data
property is set to true and
we override it at Dialect-level as follows:
public Oracle12cDialect() {
super();
getDefaultProperties().setProperty( Environment.BATCH_VERSIONED_DATA,
"true" );
}
Wouldn't it be better if the Dialect had a methods like:
boolean supportsBatchVersionedData();
and we wouldn't change the environment setting?
With this method added, the user can override the Dialect setting using the
environment variable.
With the current implementation, we always override that setting.
Vlad
10 years
SQM and Query#getReturnTypes
by Steve Ebersole
There are a few reasons I want to remove Query#getReturnTypes. At least in
its current form. Currently it simply returns the Hibernate Type(s) that
the query will return.
One of the big reasons I want to remove this method is that it is simply
not expressive enough to handle some not-so-edge-cases like dynamic
instantiation queries (we'd have no idea about a Type for the
instantiation).
So the main question is whether to simply remove that method or whether
some representation of the Query return(s) is valuable. If this
information is deemed valuable, the idea would be to develop a contract
that caters to both "normal selections" and dynamic instantiations.
10 years
HHH-9548 - stored procedures and null parameter values
by Steve Ebersole
HHH-9548[1] presents an interesting conundrum in terms of how to handle
null parameter values in regards to stored procedures and specifically in
terms of any argument defaults that might be defined on the database. At
the moment our support decides to not pass along the null in the desire to
not "over power" any defined argument defaults - if we pass the NULL, the
database would use that rather than the defined argument default.
Essentially it is one of those 50/50 calls. I started a discussion on the
JIRA, but please add your thoughts...
[1] https://hibernate.atlassian.net/browse/HHH-9548
10 years
Entity-joins (HHH-16 and HHH-7321)
by Steve Ebersole
I am working mainly on HHH-16 which requests adding support for
entity-joins (aka "ad hoc" joins).
So long-story-short, there is a simple solution with some limitations and
then a more correct solution that unfortunately requires a lot of rework in
the HQL parser.
The crux of the problem is identifier scoping in the generated SQL and how
Hibernate handles implicit joins currently in HQL.
As an example, consider a query like:
select f.id, f.customer.name, f.postDate, u.username
from FinancialRecord f
left join User u on f.lastUpdateBy = u.username
As I currently process this entity-join ("... join User on ...") I have to
attach it to the end of the FromClause. The reason I have to attach it
there is a bit of a convoluted discussion that gets into the design of the
current HQL AST model and some poor assumptions made there.
Complicating the fact that I add the entity-join to the end of the
FromClause is the fact that Hibernate currently always handles implicit
joins as theta joins.
So all told the query above is currently rendered to SQL as:
select ...
from financial_record f,
customer c
left outer join `user` u
on f.last_updt_by = u.username
where f.customer_id=c.id
So the problem with scoping is the comma. In SQL terms, that delimits the
start of a new "table reference". This is where a lot of databases diverge
on what is supported in terms of scoping references to aliases between
"table references". H2 for example is fine with this as long as the join
to `user` is an inner join; but it chokes if the join is outer.
The simply solution would seem to be to have Hibernate render the implicit
join as an ANSI-style join rather than a theta-join. However this is where
the poor design choices that I mentioned in the current parser come into
play. Basically the parser overloads the flag for implicit joins to mean
many, many things. So changing that one value really messes things up. So
that's not realistically an option. It is definitely something we want to
keep in mind for the new parser however!
Another option is to introduce a concept similar to SQL's "table reference"
into the AST model. This is essentially the same this I do in SQM with
org.hibernate.sqm.query.from.FromElementSpace. However, this is a massive
change in the parser.
I am inclined for now to simply say that implicit joins and entity-joins
cannot be combined, and to circle back to this later in terms of working
out support for using them in combination.
10 years
User guide test failure
by Gail Badner
Hi,
I just pulled and ran tests. I'm seeing the following test failing:
org.hibernate.userguide.hql.HQLTest > test_hql_between_predicate_example_2
FAILED
java.lang.AssertionError at HQLTest.java:1897
Regards,
Gail
10 years, 1 month
[Search] ElasticSearch - Progress on faceting
by Guillaume Smet
Hi,
So the good news: most of the faceting tests now pass with ES.
I rebased the patch onto master.
https://github.com/gsmet/hibernate-search/commits/elastic-facet2
and for now only one commit:
https://github.com/gsmet/hibernate-search/commit/657ecfe684e6b4e952d11274...
It's not a PR yet as it's not feature complete and there are still (a few)
tests failing.
General infrastructure
================
- I introduced a JsonBuilder to make the gson API chainable: I think it's
more readable this way. I haven't updated everything to use it (especially
the Lucene Query -> Json part is not ported yet). Should I continue with
it? Please, please, say yes :).
- All the API is now based on JsonObject so you don't have to play with
String -> Json -> String -> Json manipulation
---> would appreciate feedback on these 2 changes so that I can make
everything consistent
- I introduced a ToElasticSearch class which translates Lucene/HSearch
objects to Json. I moved the existing query translator there.
- I'm not sure building the exact same document we build for Lucene is the
way to go. I'm wondering if we should have a distinct document builder for
ES. I'll see how it works for facets not being fields.
- I made a few fixes here and there: especially the indexing didn't support
multiple values per field. I made something complicated, maybe we could
just index a JsonArray even for single values? see
https://github.com/gsmet/hibernate-search/commit/cb88b5790996442e137fab4a...
Faceting
=======
- The querying/extraction should be OK
- ES doesn't support range bounds inclusion/exclusion for range faceting so
I used the query faceting to build the range faceting
- I have to work on the mapping as having multiple facets on the same field
is not supported yet: currently I use the indexed field to build the
facets, not specific fields
- I have some additional work to do on indexing related to the above matter
Various issues
===========
- A few tests don't pass:
. ElasticSearch returns facets results even if the field doesn't exist: not
sure we can do anything about that
. A test in the WebShopTest is failing as I don't support yet faceting
based on a non existing field
. CollectionUpdateEventTest is failing: this one is weird
- I had to work around an issue with the EsDateBridge and faceting (marked
as XXX in DocumentBuilderIndexedEntity): Dates are considered to be Long
and for ES, we want them to be Strings. Would appreciate a comment on that.
Comments and thoughts appreciated.
--
Guillaume
10 years, 1 month
5.1 tentative release date
by Steve Ebersole
Just a heads up that I tentatively set Jan 27th as the release date for
5.1. Please let me know if that does not work for anyone. Also please
keep that date in mind if there is anything you want to get into 5.1.
10 years, 1 month
HipChat rooms
by Davide D'Alto
Hi,
lately there is some interest in OrientDB for Hibernate OGM.
This is not currently in the OGM roadmap but I wanted to help potential
contributros.
I've createad a room for OGM-855 using the JIRA funcitonality accessible by
Guests.
It seems though theat Guest cannot see the log of the room and that when a
user send me an invite it becomes part of the hibernate team.
Is that OK? Or do we have some limitation about accepting new users?
Am I doing something wrong?
Cheers,
Davide
10 years, 1 month
