>> Right, we could create an empty interface to flag them. > They all extend GridDialect already. Is there any easier way for an dialect provider to learn about all the facets than inspecting the type hierarchy of GridDialect?
I guess the point is to distinguish between the main datastore dialect, the decorators and the optional facets. You cannot do that looking only at the hierarchy. On Fri, Jul 24, 2015 at 2:34 PM, Hardy Ferentschik <ha...@hibernate.org> wrote: > On Fri, Jul 24, 2015 at 11:01:43AM +0200, Gunnar Morling wrote: > > > > I have been adding a facet to GridDialect and found it surprisingly > hard: > > > > > > What is a facet in this context. I've seen you guys using this term on > IRC > > > as well, > > > but I am not sure what you mean with it in relation to a GridDialect. > > > > > > > It's our way to model different (optional) capabilities of data stores. > > > > The main contract is GridDialect which offers the basic functionality > each > > store needs to support (getTuple(), insertOrUpdateAssocation() and so > on). > > Then there are several sub-types of it (e.g. QueryableGridDialect, > > OptimisticLockingAwareGridDialect etc.) which allow a dialect to expose > > advanced (or more efficient) functionality. Depending on which > capabilities > > a store exposes that way, engine will make use of it. > > Got it, thanks. > > > > which non datastore dialects was supposed to implement the facet > > > > > > non datastore dialect? Is it not one dialect per datastore? > > > > > > > Davide's answer says it :) > > +1 Thanks both of you. Always helps to understand the lingo. > > --Hardy > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
