2010/10/14 "이희승 (Trustin Lee)" <trustin(a)gmail.com>:
Galder Zamarreño wrote:
> On Oct 12, 2010, at 6:27 PM, Elias Ross wrote:
>
>> It'd be interesting if Infinispan simply could use directly (or
>> repackage) the Hibernate dialects as-is for the JDBC cache store. It
>> might save some time.
>
> I think Elias has a very good point here, can we consume Hibernate's dialects
directly instead of reimplementing the same logic again?
>
> Bringing hibernate-core might be too much but if dialect classes can be consumed
separately, we could maybe suggest the hibernate guys to separate them into a diff
module.
Yeah, I thought about that, and it's indeed a very good idea to consume
their dialect metadata implementation. However, I'm not sure they can
split it as a separate module because they are tightly coupled with some
core types.
When I initially asked for this feature to be able to customize the
SQL statements the reason was really not so much related to special
syntax needed by some dialects,
but mostly about special non-standard features which some databases provide.
A notable example is the MySQL statement "REPLACE" which is a cool
one-statement (and atomic) operation which nicely maps the put
operation.
currently when implementing a put you have to use a SELECT to verify
whether you should be using INSERT or UPDATE, and then still you're at
risk of race conditions.
Another keyword in MySQL is "DELAYED" which is perfect for this use
case and provides a significant performance improvement, but is not
supported by InnoDB
So my proposal is more related about leveraging very different
strategies provided by databases, this implies of course some low
level knowledge about dialect changes but this is not enough,
I don't see an easy way to reuse, unless it turns out to sense to add
new methods to the Dialect sand contribute the missing pieces.
Cheers,
Sanne