MySQL versus MariaDB
by Steve Ebersole
As I have developed the matrix tests against MariaDB I have had in the back
of my head whether we might want to develop a Dialect for MariaDB. As I
understand it, MariaDB does strive to remain compatible with MySQL but it
does offer some enhancements. And it might have some minor deviations.
Today I think I found one such deviation, in their respective support for
casting decimal/floating-point values. I came across this because of some
failed tests.
There are quite a few resolved issues in Jira wrt MySQL and casting. So I
have to assume these tests work on MySQL which tells me there is a
deviation in their behavior...
The tests in question (more or less) do: "select ... cast( x as big_decimal
) ...". We understand big_decimal as java.sql.Types#NUMERIC for which the
MySQL Dialect says to use "decimal" for casting purposes.
On MariaDB at least "decimal" (no precision) leads to a data trunction. We
are expecting a value like "12.399999618530273" but get back "12.0".
Because for MariaDB DECIMAL is equivalent to DECIMAL(10,0).
So as it is, for this minor case at least the MySQL dialects work against
MySQL databases (we assume) but fail against MariaDB databases.
The other difficulty with a dialect specific for MariaDB is
auto-detection. The MariaDB JDBC drivers report the underlying database as
mysql.
10 years, 10 months
database names and identifier length
by Steve Ebersole
Do we want to consider automatically applying known database limits on
various identifier lengths? This is trickier to implement than it might
sound. And it would definitely need to wait for the reworking of
annotation binding. But in general I wonder if y'all see this as a
desirable feature. And if so, should that be just for implicit names? Or
explicit names as well?
10 years, 10 months
Preparing to release 4.2.20.Final and 4.3.11.Final
by Gail Badner
I am starting with the 4.2.20.Final release now. After I finish that, I may still push a few fixes before starting the release for 4.3.11.Final.
Please don't push push to 4.2 or 4.3 branches.
Thanks!
Gail
10 years, 10 months
Reminder: Testing on WildFly 10 requires Java 8
by Gunnar Morling
Hi,
A quick reminder for those projects that wish to run integration tests on
WildFly 10: This requires the build to run on Java 8.
Preferably, this should be enforced e.g. through the Maven enforcer plug-in
or similar. Running tests on WF 10 on an older JDK fails. The cause is a
bit tough to find (JBoss modules refuses to load the WF 10 modules which
happens very early, so there is no entry in server.log).
Of course our own projects still can target earlier Java versions, it's
only WF integration tests which are affected by this.
Cheers,
--Gunnar
10 years, 10 months
HQLScrollFetchTest
by Steve Ebersole
Gail, etal.
I have a lot of questions in regards to HQLScrollFetchTest:
1) First is the split between it and NoIdentityHQLScrollFetchTest. I do
not fully understand why this split exists. They test the same thing
(literally; NoIdentityHQLScrollFetchTest extends HQLScrollFetchTest and
just supplies a different mapping). The mapping says something about
Sybase requiring the pk to be an IDENTITY in order for it to support
scrolling results. But I could find no mention of that anywhere via google
search.
2) HQLScrollFetchTest#testScroll is skipped for a huge list of dialects. I
only even started looking at this class because this test is failing when I
try to run it against MySQL/MariaDB (these are not listed for skipping).
But looking at the test, there is no expectation that this should ever work
for any database. The reason being that we completely expect the user to
"properly order" the query results for scrolling queries with fetches. The
test does not do that. TBH, I do not know what Dialect this test would
actually pass against.
10 years, 10 months
org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest
by Gail Badner
I think this is probably just a bug in the test, but I want to mention it in case there is a real bug here.
When I run the unit tests multiple times, sometimes I see WarehouseItem created with:
create table WarehouseItem (
id integer generated by default as identity,
version integer not null,
qtyInStock decimal(19,2),
vendor_id integer,
item_id integer,
primary key (id)
)
Sometimes WarehouseItem is created with:
create table WarehouseItem (
id integer generated by default as identity,
version integer not null,
qtyInStock decimal(19,2),
ITEM_ID integer not null,
VENDOR_ID integer not null,
primary key (id)
)
I started seeing this only recently (last couple of weeks or so).
In the WarehouseItem class [1], the following join column names are specified: vendor_id, VENDOR_ID, item_id, ITEM_ID.
I'm sure that making the column names consistent (upper or lower) case would make the table DDL consistent. I want to make sure I don't mask a real bug by making this change.
Is this a bug in the test, or a bug in how column names are processed?
[1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
10 years, 10 months
Proposal for a Redis module in Hibernate OGM
by Mark Paluch
Hi there,
I created a Redis module for Hibernate OGM, based on OGM 4.2. Redis is a
Key-Value store supporting Lists, Hashes (Maps), Sorted Sets, ...
I took the Infinispan/CouchDB approach storing entities and associations as
JSON documents within Redis Hashes. A Map<Object, Map<Object, Object>>
corresponds with a Redis Hash.
The entity table maps to the Hash Id, the entity Id to the key of the hash
and the set of columns is enclosed within a JSON (currently). Supported
features are:
* Composite Id's
* Embedded associations
* External associations
and I guess many more, that I'm currently not aware of :-)
There are various ways (JSON, Java-serialized simulating Documents) how to
store data within Redis.
Another approach could be storing Tuples within Redis more native, since
they are in the end Maps, somehow. However, mapping tuples to Redis fit a
native storage but raises questions about Id's, limited data type support
(there is no equivalent for nested lists/maps). So the more native approach
would require distributing data amongst various data types, depending on
the supported features, and would require more IO's.
My impl can be used to interoperate with other clients from the C, Ruby,
Python, Node.js, ... worlds. The JSON is clean and does not look awkward on
the first look.
The current code can be found below
https://github.com/mp911de/hibernate-ogm/tree/redis. Most TCK tests pass,
only some 15 tests fail. Mostly due to enum and JTA support. Couldn't
figure out, how to fix it, so need your help to figure it out.
Hope, I made you hungry for the Redis OGM module. Let's start a discussion
based on my proposal for inclusion and let's see, where we end up.
Best regards, Mark
10 years, 10 months
ORM - location of generated sources
by Gunnar Morling
Hi,
The build for hibernate-core generates sources using Antlr which end up in
target/generated-src/antlr/main, e.g. GeneratedOrderByFragmentParser.java.
The weird thing is that the generated files are located right within this
directory, i.e. there is *no* directory hierarchy resembling the package
structure. The files have package declarations such as
"org.hibernate.sql.ordering.antlr", though.
Apparently, this works in the Gradle build (no errors due to that), but in
my IDE I am getting tons of compile errors due to the mismatch of package
declaration and file location. Interestingly, the files also end up in the
right place in the hibernate-core.jar, so I assume that there is some Magic
in place at the Gradle level which deals with that stuff.
Does anyone know how to make it work in the IDE as well?
Thanks,
--Gunnar
10 years, 10 months
ORM - Download of DTD failed
by Gunnar Morling
Hi,
I noticed an interesting failure of HibernateCacheTest from the
"hibernate-ehcache" module in a recent ORM CI build [1].
It failed to obtain hibernate-configuration-3.0.dtd from SourceForge (there
was some service outage at SF at this time). Apart from the fact that the
test uses the legacy URL (I'll fix that), I am wondering why the config
parser tried to obtain the DTD remotely in the first place. We have
LocalXmlResourceResolver in place which is there to prevent this. An indeed
if I debug the test locally, I don't get to the place where it would
download it from remote.
Anyone with an idea why that would happen on CI?
Thanks,
--Gunnar
[1]
http://ci.hibernate.org/job/hibernate-orm-master-h2/988/testReport/junit/...
10 years, 10 months
