Apache Trafodion Dialect
by Brett Meyer
All, we've been approached by the team responsible for the Apache
Trafodion project, an "SQL-on-Hadoop" solution. They've developed a
Dialect, are willing to contribute it, and are willing to maintain it
long term. The latter has been a requirement for a while -- we have too
many Dialects that were contributed then abandoned.
However, the other requirement is actual demand by community users. So,
out of curiosity, would anyone actually use it? I'm not at all familiar
with the project or space, but it definitely sounds interesting. If
this Dialect would be helpful, please add your vote to the JIRA:
https://hibernate.atlassian.net/browse/HHH-10216
9 years, 12 months
5.0.3
by Steve Ebersole
A reminder that 5.0.3 is slated for 2 days from now. There are currently
10 unresolved issues scheduled for it. If you scheduled an issue for 5.0.3
please make sure it is resolved soon.
9 years, 12 months
jandex-binding work
by Steve Ebersole
Wanted to point out the jandex-binding version in Jira that is the work to
pull the annotation binding and Jandex usage from metamodel into upstream.
I do not plan on pulling over the shared (shared between hbm.xml and
annotations) Binder code from metamodel. This will just be a focus on the
code that uses Jandex instead of HCANN and the "binding context" code I
already pulled over upstream as part of 5.0.
The reason I mention this is that I started some work on this this week.
For now I will work in my fork, but I do want to start thinking through the
target versions for incorporating these major redesigns we have going).
My plan for this stuff is to deprecate hbm.xml binding. We have discussed
this before. So along with this, I will pull over the unified orm.xml XSD
and we will start providing mapping support for that. On metamodel, there
is some on-the-fly transformation code, but I think we will put that on the
back burner for now. I see the next major rev of this work as ripping out
the hbm.xml binding code completely but still for a short time continuing
to support a subset of hbm.xml mapping via this on-the-fly
transformation[1]. And there will also be a (build time) transformation
tool based on that code.
[1] - The things that we cannot readily transform is a very small set of
things. Really property-ref is the only thing that comes to mind.
10 years
OGM on WildFly11 ...
by Scott Marlow
Hi,
After our discussion last week about improving OGM use on WildFly (by
adding a Jipijapa integration adapter for OGM), I wanted to share some
feedback.
A few years ago, we decided that having a 1-1 (bidirectional) dependency
between ORM + the Jipijapa adapter was okay. With OGM, we need to
discuss again. I think that our choices are to update ORM properties
that identify class names, to also allow a class instance to be
specified. This doesn't have to be all ORM integration properties but
likely should include the ones currently set by Jipijapa.
hibernate.cache.region.factory_class is currently used by Jipijapa to
specify the name of the cache region factory class name. I think this
implies that the Hibernate ORM classloader will need access to the
Jipijapa supplied class (as mentioned above). Currently, in WildFly 10,
the ORM module (org.hibernate:main) depends on the
org.hibernate.jipijapa-hibernate5:main module to resolve this class.
Some alternatives to changing hibernate.cache.region.factory_class to
allow a class to be specified:
1. OGM could bundle the ORM classes or depend on a duplicate ORM module
(with a dependency on a jipi_ogm module).
2. OGM could avoid using the 2lc on WildFly.
Any preferences or suggestions?
Scott
10 years
read/write fragments and id column(s)
by Steve Ebersole
HHH-4440[1] added the read/write fragment support. However, as reported
under HHH-9808[2] that support is not consistent for id column(s).
The first piece is missing write fragment support. The second piece is
inconsistent application of the read fragments in generated SQL.
So as a first question... do we want to support read/write fragments for id
column(s)?
Assuming yes...
Generally speaking we want read/write fragments in reflective pairs, so I
am not sure specifically why support for write fragments is not here. I
guess there are some cases where it might not make sense (IDENTITY
generated columns, e.g.).
WDYT?
[1] - http://hibernate.atlassian.net/browse/HHH-4440
[2] - http://hibernate.atlassian.net/browse/HHH-9808
10 years
SQM - alias registry
by Steve Ebersole
At the moment the alias registry is global for the whole query. I propose
that we should scope this by "query spec" (combined with parent). The
reason being that reusing the same alias in unrelated subqueries is
perfectly fine.
select ...
from Customer c
where c.id in (
select o.customer.id
from Order o
...
)
or c.id in (
select c1.id
from Outstanding o
...
)
Here the aliases `o` don't ever infringe on each other. So imo we should
allow that.
The piece about checking the parent is for a case like:
select ...
from Customer c
where c.id in (
select c.id
from Order o
join o.customer c
...
)
Here the aliases `c` do infringe. In the subquery, we don't really know
which reference the `c` alias should resolve to. We *could* here assuming
that the subquery is uncorrelated. Bu without this rule we really would
not know that the subquery is correlated. Hopefully that makes sense, what
I am getting at.
WDYT?
10 years
