[infinispan-dev] TableManipulation refactoring

[Manik Surtani]

On 14 Oct 2010, at 12:52, 이희승 (Trustin Lee) wrote:

> Sanne Grinovero wrote:
>> 2010/10/14 "이희승 (Trustin Lee)" <trustin at 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.
> 
> We will of course take that aspect into account.  Maybe we need a better
> name, since 'dialect' seems to result in confusion. :)

Why would it result in confusion?  I think it is perfectly clear.

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org