Re: [infinispan-dev] TableManipulation refactoring

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. :)