Usability issue with Ignite configuration

[dsetrakyan]

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.

[Alexey Goncharuk]

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.

2015-08-12 9:45 GMT-07:00 Dmitriy Setrakyan <[hidden email]>:

> 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.
>

[Vladimir Ozerov]

May be we can return not only cache instance, but also a boolean defining
whether a cache was created by this call or not?
E.g.:

IgniteCache getOrCreateCache(...);

IgniteCache getOrCreateCache(..., CacheCreateResult);

class CacheCreateResult {
    boolean isCreated();
}

On Fri, Aug 14, 2015 at 3:56 AM, Alexey Goncharuk <
[hidden email]> 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.
>
> 2015-08-12 9:45 GMT-07:00 Dmitriy Setrakyan <[hidden email]>:
>
> > 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.
> >
>

[Alexey Kuznetsov-2]

Or we could have isCreated() property on cache itself.

On Fri, Aug 14, 2015 at 12:03 PM, Vladimir Ozerov <[hidden email]>
wrote:

> May be we can return not only cache instance, but also a boolean defining
> whether a cache was created by this call or not?
> E.g.:
>
> IgniteCache getOrCreateCache(...);
>
> IgniteCache getOrCreateCache(..., CacheCreateResult);
>
> class CacheCreateResult {
>     boolean isCreated();
> }
>
> On Fri, Aug 14, 2015 at 3:56 AM, Alexey Goncharuk <
> [hidden email]> 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.
> >
> > 2015-08-12 9:45 GMT-07:00 Dmitriy Setrakyan <[hidden email]>:
> >
> > > 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.
> > >
> >
>

--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[Vladimir Ozerov]

This way you will not know who exactly created the cache. As a result you
cannot be certain whether your call to getOrCreateCache() created a cache
or you just received already existing instance.

On Fri, Aug 14, 2015 at 8:55 AM, Alexey Kuznetsov <[hidden email]>
wrote:

> Or we could have isCreated() property on cache itself.
>
> On Fri, Aug 14, 2015 at 12:03 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > May be we can return not only cache instance, but also a boolean defining
> > whether a cache was created by this call or not?
> > E.g.:
> >
> > IgniteCache getOrCreateCache(...);
> >
> > IgniteCache getOrCreateCache(..., CacheCreateResult);
> >
> > class CacheCreateResult {
> >     boolean isCreated();
> > }
> >
> > On Fri, Aug 14, 2015 at 3:56 AM, Alexey Goncharuk <
> > [hidden email]> 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.
> > >
> > > 2015-08-12 9:45 GMT-07:00 Dmitriy Setrakyan <[hidden email]>:
> > >
> > > > 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.
> > > >
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

[dsetrakyan]

On Thu, Aug 13, 2015 at 10:03 PM, Vladimir Ozerov <[hidden email]>
wrote:

> May be we can return not only cache instance, but also a boolean defining
> whether a cache was created by this call or not?
> E.g.:
>
> IgniteCache getOrCreateCache(...);
>
> IgniteCache getOrCreateCache(..., CacheCreateResult);
>
> class CacheCreateResult {
>     boolean isCreated();
> }
>

I don't think I like this solution. The point is to improve usability, but
this change will decrease it in my view.

>
> On Fri, Aug 14, 2015 at 3:56 AM, Alexey Goncharuk <
> [hidden email]> 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.
> >
> > 2015-08-12 9:45 GMT-07:00 Dmitriy Setrakyan <[hidden email]>:
> >
> > > 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.
> > >
> >
>

[dsetrakyan]

On Thu, Aug 13, 2015 at 5:56 PM, Alexey Goncharuk <
[hidden email]> 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 <[hidden email]>:
>
> > 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.
> >
>

[Valentin Kulichenko]

I think we should just throw an exception in this case. Providing two
configurations for one cache looks like incorrect usage for me.

-Val

On Thu, Aug 13, 2015 at 11:43 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Thu, Aug 13, 2015 at 5:56 PM, Alexey Goncharuk <
> [hidden email]> 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 <[hidden email]>:
> >
> > > 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.
> > >
> >
>

[dsetrakyan]

On Fri, Aug 14, 2015 at 12:47 AM, Valentin Kulichenko <
[hidden email]> 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 <[hidden email]
> >
> wrote:
>
> > On Thu, Aug 13, 2015 at 5:56 PM, Alexey Goncharuk <
> > [hidden email]> 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 <[hidden email]>:
> > >
> > > > 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.
> > > >
> > >
> >
>

[Vladimir Ozerov]

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 <[hidden email]>
wrote:

> On Fri, Aug 14, 2015 at 12:47 AM, Valentin Kulichenko <
> [hidden email]> 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 <
> [hidden email]
> > >
> > wrote:
> >
> > > On Thu, Aug 13, 2015 at 5:56 PM, Alexey Goncharuk <
> > > [hidden email]> 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 <[hidden email]>:
> > > >
> > > > > 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.
> > > > >
> > > >
> > >
> >
>

[yzhdanov]

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 <[hidden email]>:

> 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 <[hidden email]>
> wrote:
>
> > On Fri, Aug 14, 2015 at 12:47 AM, Valentin Kulichenko <
> > [hidden email]> 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 <
> > [hidden email]
> > > >
> > > wrote:
> > >
> > > > On Thu, Aug 13, 2015 at 5:56 PM, Alexey Goncharuk <
> > > > [hidden email]> 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 <[hidden email]
> >:
> > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>