+1 for the usage question! Would be nice to understand the use case of it too.
And in this specific case, I'd also wonder if the same use case
wouldn't be fulfilled better by an Hibernate OGM dialect.
On 26 October 2015 at 18:13, Brett Meyer wrote:
> All, we've been approached by the team respon
That's indeed interesting. It is like a RDBMS that uses Hadoop as the
underlying storage engine.I see that others have managed to run the TPC-C suite
against Trafodion too:
http://hammerora.sourceforge.net/hammerdb_trafodion_oltp.pdf
I think this could be a good opportunity for Hibernate to appr
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.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https:
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 tha
Hey Steve,
The changes that you describe below will have almost no impact on the tooling.
It requires the removal of IColumn.getValue() but AFAICS this functionality is
only used twice and I am even not sure if it should be used where it is used. I
am pretty sure there is an easy way to deal wi
Hey Steve,
The changes that you describe below will have almost no impact on the tooling.
It requires the removal of IColumn.getValue() but AFAICS this functionality is
only used twice and I am even not sure if it should be used where it is used. I
am pretty sure there is an easy way to deal wi
So here are the general proposals per object:
1) Column - The main change proposed is to distinguish between the logical
name and physical name of a Column, so I propose that we keep both on the
Column for easier access. I also propose that we remove Value from being
stored on Column; it is an aw
