Re: [infinispan-dev] TableManipulation refactoring

On 14 Oct 2010, at 12:52, 이희승 (Trustin Lee) wrote: > Sanne Grinovero wrote: >> 2010/10/14 "이희승 (Trustin Lee)" <trustin(a)gmail.com&gt;: >>> 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.