[hibernate-dev] [OGM] GridDialect facets

[Gunnar Morling]

2015-07-24 9:56 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I have been adding a facet to GridDialect and found it surprisingly hard:
>
> * I was not sure which non datastore dialects was supposed to implement
> the facet nor really how to find these non datastore dialects. I am talking
> about GridDialectLogger, ForwardingGridDialect and
> InvokedOperationsLoggingDialect. I am sure there are more of these non
> datastore dialects but I haven’t found them.
>

If there are better ideas for this I am all for it. So far I didn't find
one (but then I didn't put much time into thinking about it as it didn't
occur as a huge issue to me so far).

* ForwardingGridDialect is the base for all dialects wishing to apply some
decorating logic (logging, batch aggregation etc.) prior to delegating to
the underlying dialect, so I don't think it'll go away.
* GridDialectLogger: I am no big fan of this either. Maybe we can drop it
once we implemented logging of actual datastore interactions in the
dialects?
* InvokedOperationsLoggingDialect: Used in tests for asserting invoked
dialect operations; It's very useful for that. I initially hoped the
compensation SPI could be re-used for that, but there we only collect
mutating methods, i.e. no calls to getTuple() etc. It could be implemented
generically w/ a proxy, there should be no harm to that as it's test-only

* Adding one method, to a facet means having to go to a lot of places to
> write all these logging and delegating logics. Changing a method sig a
> least gives you the help of the compiler but not for adding them.
>

When adding a new facet, the first step would be to add it to
ForwardingGridDialect. Then you'd have to decide to which of the auxiliary
dialect decorators you need to add it (e.g. for logging, batching).


> * Find how consumers of the facet are supposed to use them was not obvious
> to me. It seems a given consumer stores all the possible facets as class
> field and do a null check before using them.
>

Yes, that's the usage pattern. Alternative would be to rely on getting the
dialect only + instanceof, but the current one seems nicer to me. Again, if
there a better ideas, let's change it. Maybe some unwrap() or as() method
on an internal GridDialect extension, GridDialectImplementor?


> * when I finally ran my tests everything exploded because each facet must
> have a MyFacetInitiator
> * when I added the initiator, it still blew up at my face because each
> Initiator must be listed in the OgmIntegrator
>

Ok, but that's standard service registry business. Not sure whether there
is a way around it.


> * I’m also concerned about facet discoverability, I don’t think it’s
> trivial for a dialect implementor to get the list of facets easily, which
> will tend to bring minimal dialects without the advanced features.
>

I think they are apparent in the type hierarchy. We could start some grid
dialect developer guide and describe all the optional facets there.

I wonder if and / or how we should improve that state of affairs.
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev