I agree with Val - exception should be thrown if code configuration is not compatible with the one in XML config.
As far as return some indication if cache was created via this call - this does not seem very important to me. --Yakov 2015-08-16 19:21 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > We already have a method GridCacheProcessor.checkCache() which accepts two > cache configurations - local and remote - and decides whether they are > compatible. > Looks like we just need to refactor it a bit so that it can be used for > "getOrCreateCache" scenario. > > However, whatever checks we perform, there still be some scenarios which is > critical for users, but cannot be checked by Ignite directly. First of all > I am talking about user-defined resources. And it will end up in the same > usability problem. This is why I think we *MUST* give user ability to know > whether cache was actually created by his call to getOrCreateCache() or > not. May be using additional returned boolean flag, may be using optional > closure which is executed if cache is created, whatever. > > On Fri, Aug 14, 2015 at 9:39 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > On Fri, Aug 14, 2015 at 12:47 AM, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > I think we should just throw an exception in this case. Providing two > > > configurations for one cache looks like incorrect usage for me. > > > > > > > I don't think we should make assumptions here. Let's just throw an > > exception if configurations do not match in a critical way. > > > > > > > > > > -Val > > > > > > On Thu, Aug 13, 2015 at 11:43 PM, Dmitriy Setrakyan < > > dsetrak...@apache.org > > > > > > > wrote: > > > > > > > On Thu, Aug 13, 2015 at 5:56 PM, Alexey Goncharuk < > > > > alexey.goncha...@gmail.com> wrote: > > > > > > > > > In this case, since user called getOrCreateCache(), Ignite did not > > > > create a > > > > > cache because it already existed and also did not throw an > exception > > > > > because method should return existing cache if a cache with the > same > > > name > > > > > already exists. > > > > > > > > > > We may want to implement a check to verify that cache > configurations > > > > match, > > > > > but I have no idea how to compare cache configurations given that > > they > > > > may > > > > > contain user-defined objects, such as store factories. > > > > > > > > > > > > > Can we to the least compare what we can and skip whatever we cannot? > > For > > > > example, for factories, we can make sure that the class names match. > > > > > > > > I definitely think that we need some level of validation here. Users > > keep > > > > getting burned on this issue. > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > 2015-08-12 9:45 GMT-07:00 Dmitriy Setrakyan <dsetrak...@apache.org > >: > > > > > > > > > > > Igniters, > > > > > > > > > > > > After looking at the comment in the IGNITE-1240 [1], I got > confused > > > on > > > > > how > > > > > > Ignite configuration works. It seems to me that we have a big > > > usability > > > > > > issue there. > > > > > > > > > > > > For example, can someone tell me what happens now if a user > > provides > > > > the > > > > > > configuration in an XML file and then also specifies the > > > configuration > > > > in > > > > > > code? > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-1240 > > > > > > > > > > > > Thanks, > > > > > > D. > > > > > > > > > > > > > > > > > > > > >
