[ http://opensource.atlassian.com/projects/hibernate/browse/OGM-79?page=com... ] Emmanuel Bernard updated OGM-79: -------------------------------- Issue Type: Sub-task (was: Improvement) Parent: OGM-105 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/OGM-79?page=com... ] Emmanuel Bernard commented on OGM-79: ------------------------------------- Here is a discussion between Emmanuel and Sanne on the role of a DatastoreManager and the GridDialect {quote} sannegrinovero hi emmanuel 17:12 sannegrinovero still here 17:12 emmanuel sannegrinovero: yep 17:12 emmanuel So in OGM 17:12 emmanuel if you look at GridDialect 17:12 emmanuel we do pass infinispan's Cache methoid 17:12 emmanuel That's obviously not very portable 17:13 emmanuel I have been thinking about ways to solve the problem 17:13 emmanuel I se 17:13 emmanuel I initially thought about creating an abstraction for Cache and replace the API verbatim 17:13 sannegrinovero I was going to talk you about the same thing 17:14 emmanuel But I now think that we probably should internalize Cache lookup into a NoSQL provider specific abstraction 17:14 emmanuel Technically form the key the provider is able to lookup the right cache 17:14 emmanuel I've looked at the code and we do cache lookup right before calling the dialect anyways 17:15 sannegrinovero even more than that, you might want to extract the specific operations and define them on the dialect instead of returning the Cache 17:15 emmanuel Not following you 17:15 sannegrinovero because some "dialects" might need some specific tricks to do some stuff better 17:15 sannegrinovero well right now you expose the Map API to the OGM engine 17:15 emmanuel the dialect already does define generic operations 17:16 emmanuel no 17:16 emmanuel I expose the Tuple API 17:16 sannegrinovero but Infinispan works better if you enable the specific Flag (s) to tune each specific need 17:16 sannegrinovero ah right, was confused 17:16 emmanuel So that's my current thinking 17:17 emmanuel We have two approaches I guess 17:17 emmanuel Have the notion of DatastoreManager that is passed to the dialect 17:17 emmanuel or leave the dialect do all the work 17:17 emmanuel I'm not sure what's best yet 17:18 emmanuel For sure, the engine will only interact with the dialect 17:18 emmanuel (except for initialization) 17:18 emmanuel Any thoughrs? 17:19 sannegrinovero is abstractin Cache the only reason, or are there more ? 17:19 sannegrinovero just to figure out which problems need to be solved 17:19 sannegrinovero My idea is that at some point we will need two levels of asbtraction, an intermediate layer to talk to all key/value stores, and a higher layer which doesn't care of it's key/value or what, and the lowest coupled to Infinispan 17:20 sannegrinovero also, for the specific k/v stores we could use the JSR-347 API 17:22 emmanuel sannegrinovero: I don't know but I hope th tuple API is generic enough for all noSQL solutions 17:22 emmanuel Loader and Persisters might be specific though 17:22 sannegrinovero right 17:23 emmanuel My concern with delegating cache lookups to extension points is the following 17:23 emmanuel putting all entities in a single cache or splitting one entity type per cache becomes a dialect implementation detail 17:23 emmanuel which I am not found of 17:23 sannegrinovero right, in fact some users might even prefer to use OGM with a single cache for all. 17:24 sannegrinovero don't know if you noticed it too, but the ServiceRegistry thing in Hibernate Core 4 is slowing down things, not much but it does. 17:24 sannegrinovero it might be a great pattern to enable the flexibility needed for H4, but if we can design it in such a way to avoid lookups per operation that would definitely be better 17:25 emmanuel sannegrinovero: that's ok we can cache services registry lookups down the road 17:26 emmanuel eg in the persister and the loaders 17:27 sannegrinovero so in practice the question is if we want the InfinispanDialect to keep references to the CacheManager ? 17:28 sannegrinovero that would be the approach of "leaving all the work to the Dialect" right? 17:28 emmanuel If I try and summarize what is specific to a NoSQL provider and thus abstracted is: - how to create, update, delete entities (fundamental op) - how to create, update, delete collections (fundamental op) - how to boot the DatastoreManager (ie how to connect to the datastore engine) - how to access a given datastore (or cache in ispn's cache) - possibly later which persister / loader family to use 17:29 sannegrinovero and queries. Some engines do have queries. 17:30 emmanuel sannegrinovero: right about queries amd ref to the cache manager 17:31 emmanuel s/amd/and the/ 17:31 sannegrinovero what about transactions, is it possible some might have a transactions "surrogate" which needs to be accessed in different way? 17:32 emmanuel I guess 17:32 emmanuel we will see 17:32 sannegrinovero yes I'm guessing too, but don't know if any have such a thing. 17:32 sannegrinovero but you could consider that another point for your list of stuff which needs possibly to be delegated to the dialect 17:33 emmanuel I guess we do need a DatastoreManager API that will be responsible for answering all these questions 17:33 emmanuel the question remaining is do we keep a notion of dialect 17:33 emmanuel something tells me yes 17:33 emmanuel for example in ISPN, one can thing of different storage strategies 17:33 emmanuel implemented by dialects 17:33 sannegrinovero I'm also thinking so, but maybe we should constrain it's meaning to some operations, it will not be fit for all things. 17:34 emmanuel whereas the rest of the Datastore bootstrap does not changes 17:34 sannegrinovero so the dialect could be the thing which abstracts CRUD for entities and relations 17:34 sannegrinovero but nothing else 17:34 emmanuel like it is today yes 17:34 emmanuel though it does use NoSQL native APIs 17:34 sannegrinovero a bit tricky the relations part, as it might benefit from queries instead of FG Maps 17:35 sannegrinovero so it would depend on the query engine 17:35 emmanuel that's unlike the Hibernate Core dialects that is more a question / answer API used by the engine 17:35 emmanuel It looks like GridDialects will need access to the DatastoreManager anyways 17:36 sannegrinovero right, that's my thought as well 17:36 sannegrinovero but are you going to pass it on a per-invocation, or at initialization? it looks like to me a good candidate for a final 17:38 emmanuel One thing I woner about is whether or not the user should be involved in these choices / decisions 17:38 emmanuel ie can a user plug a diff query engine (assuming we have several ) 17:39 sannegrinovero mm... like sharding ideas, on multiple instances of a nosql, or possibly on different kinds ? 17:39 sannegrinovero yes I would make that possible, but is of course not a priority 17:39 emmanuel if the user is involved, then the DatastoreManager can provide "default anwers for the dialect, query engine etc 17:39 emmanuel but nto the final one 17:39 emmanuel re final. yes that will be passed at initialization but… interfaces, initialization and final values don't play well together as you know 17:40 emmanuel so should a dialect have a initialize(Something) method 17:40 emmanuel or should we enforce a Constructor(Something) 17:41 emmanuel (not type safe 17:41 emmanuel ) 17:41 sannegrinovero why not typesafe? 17:41 sannegrinovero you know I like constructors 17:41 emmanuel If I forgot the Constructor in the dialect, I'll get a runtime exception 17:41 emmanuel not a compile time exception 17:42 sannegrinovero right but you'll get it immediately at boot time, not "after a while in production.." 17:42 emmanuel correct 17:42 sannegrinovero well I'm fine for initialization methods too, it's just more tricky to get it right when the service is accessed concurently 17:43 sannegrinovero but it's doable 17:43 sannegrinovero and that implementation detail won't be checked at compile time either 17:43 emmanuel Multi cores are a thing of the past anyways 17:44 emmanuel don't bother with synchronization 17:44 sannegrinovero right now it's the eras of persistence framework which support SERIALIZABLE only 17:44 emmanuel and transactional datagrids that use hypra optimistic tx strategies aka some commits win 17:45 sannegrinovero 17:45 sannegrinovero I'll have to go in a couple of minutes, or gf kills me 17:46 sannegrinovero in an unrelated parenthesis, I found this proposal from Stark very interesting, if you have time to ponder about the possibilities: community.jboss.org/thread/174167 17:46 emmanuel np 17:47 sannegrinovero I think we concluded the dialect will need the instance right? 17:47 emmanuel yes we concluded two interfaces 17:48 emmanuel one "controler" and one "dialect" 17:48 emmanuel I'll explore that next week {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira