2015-07-24 9:56 GMT+02:00 Emmanuel Bernard <emman...@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@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
