[infinispan-dev] TableManipulation refactoring

["이희승 (Trustin Lee)"]

Manik Surtani wrote:
> 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.

Because 'dialect' is just metadata while what we are trying to write is
an SQL builder that generates an optimized SQL for the data store's
certain operation.

-- 
Trustin Lee - http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 290 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101123/dbd9f0b9/attachment-0001.bin