> 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 <hardy(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev