Re: Cache Configuration Templates

[Dave Harvey]

The SQL interface does not allow you to configure details of the cache
except via templates.   The use case is I want to start with the cluster
specific defaults for a cache, and add some others.

I can create a empty real cache that has the defaults, and use its
configuration in the CacheConfiguration constructor,   but we already have
templates.

On Wed, Aug 29, 2018 at 4:55 AM, Ilya Kasnacheev 
wrote:

> Hello!
>
> Why don't you just use CREATE TABLE for that? I doubt there will be any
> significant overhead even if you never use any SQL and only use Cache API
> after that.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 28 авг. 2018 г. в 17:37, Dave Harvey :
>
>> I did a suggested edit adding the Spring configuration of templates.
>> The rest of the current semantics seem a bit odd, so I was somewhat at a
>> loss as to what to write.
>>
>> The wildcard approach means that I have to know the structure of the
>> cache name a priori.   Seems like there should be a Java API that is
>> equivalent to CREATE TABLE with allows a cache to be created from an
>> arbitrary template name, as well as a way to retrieve a copy of the
>> CacheConfiguration from a template name, so that it can subsequently be
>> enhanced.  I would assume that Ignite.cache(templateName) would fail if
>> the template name has a "*" in it, and instantiate a cache otherwise.
>>
>> On Mon, Aug 27, 2018 at 7:31 AM, Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com> wrote:
>>
>>> Hello!
>>>
>>> Unfortunately, cache templates are not documented that good. AFAIK they
>>> were mostly implemented to be able to reference to complex cache
>>> configurations with CREATE TABLE.
>>>
>>> As far as my understanding goes, caches from cacheConfigurations are
>>> actually started when grid starts.
>>>
>>> 1) I think that only the first one will be used to create a cache. Even
>>> if you join a node with distinct cacheConfigurations to the cluster, and it
>>> already has some caches started, those will just be re-used (by name).
>>> 2) Yes, you can have a cacheConfiguration with name "prefix*", which
>>> will lead to a) not starting this cache on grid start, and b) when you
>>> start a cache "prefix1" it will use configuration from template. There's a
>>> test for it named IgniteCacheConfigurationTemplateTest in code base.
>>> 3) Nothing will happen, it will return early if such cache already
>>> exists.
>>> 4) Yes.
>>> 5) Good question, I will have to check that. Still I won't rely on that
>>> and just always have this configuration around.
>>> 6) See above about the '*'.
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> сб, 25 авг. 2018 г. в 0:55, Dave Harvey :
>>>
 I found what I've read in this area confusing, and here is my current
 understanding.

 When creating an IgniteConfiguration in Java or XML, I can specify the
 property cacheConfiguration, which is an array of
 CacheConfigurations.  This causes Ignite to preserve these configurations,
 but this will not cause Ignite to create a cache. If I call
 Ignite.getOrCreateCache(string), if there is an existing cache, I will
 get that, otherwise a new cache will be created using that configuration.

 It seems like creating a cache with a configuration will add to this
 list, because Ignite.configuration.getCacheConfiguration() returns all
 caches.

 I can later call Ignite.addCacheConfiguration(). This will add a
 template to that list.

 Questions:
 1)  what happens if there are entries with duplicate names on
 IgniteConfiguration.setCacheConfiguration()   when this is used to
 create a grid?
 2) There was mention in one e-mail talking about a convention where
 templates have "*" in their name?
 3) What happens if addCacheConfiguration() tries to add a duplicate
 name?
 4) Is a template simply a cache that not fully instantiated?
 5) What about template persistence?   Are they persisted if they
 specify a region that is persistent?
 6) My use case is that I want to create caches based some default for
 the cluster, so in Java I would like to construct the new configuration
 from the a template of a known name.   So far, I can only see that I can
 call Ignite.configuration.getCacheConfiguration() and then search the
 array for a matching name.   Is there a better way?


 *Disclaimer*

 The information contained in this communication from the sender is
 confidential. It is intended solely for use by the recipient and others
 authorized to receive it. If you are not the recipient, you are hereby
 notified that any disclosure, copying, distribution or taking action in
 relation of the contents of this information is strictly prohibited and may
 be unlawful.

 This email has been scanned for viruses and malware, and may have been
 automatically archived by *Mimecast Ltd*, an innovator in Software as
 a Service (SaaS) 

Re: Cache Configuration Templates

[Ilya Kasnacheev]

Hello!

Why don't you just use CREATE TABLE for that? I doubt there will be any
significant overhead even if you never use any SQL and only use Cache API
after that.

Regards,
-- 
Ilya Kasnacheev


вт, 28 авг. 2018 г. в 17:37, Dave Harvey :

> I did a suggested edit adding the Spring configuration of templates.
> The rest of the current semantics seem a bit odd, so I was somewhat at a
> loss as to what to write.
>
> The wildcard approach means that I have to know the structure of the cache
> name a priori.   Seems like there should be a Java API that is equivalent
> to CREATE TABLE with allows a cache to be created from an arbitrary
> template name, as well as a way to retrieve a copy of the
> CacheConfiguration from a template name, so that it can subsequently be
> enhanced.  I would assume that Ignite.cache(templateName) would fail if
> the template name has a "*" in it, and instantiate a cache otherwise.
>
> On Mon, Aug 27, 2018 at 7:31 AM, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com> wrote:
>
>> Hello!
>>
>> Unfortunately, cache templates are not documented that good. AFAIK they
>> were mostly implemented to be able to reference to complex cache
>> configurations with CREATE TABLE.
>>
>> As far as my understanding goes, caches from cacheConfigurations are
>> actually started when grid starts.
>>
>> 1) I think that only the first one will be used to create a cache. Even
>> if you join a node with distinct cacheConfigurations to the cluster, and it
>> already has some caches started, those will just be re-used (by name).
>> 2) Yes, you can have a cacheConfiguration with name "prefix*", which will
>> lead to a) not starting this cache on grid start, and b) when you start a
>> cache "prefix1" it will use configuration from template. There's a test for
>> it named IgniteCacheConfigurationTemplateTest in code base.
>> 3) Nothing will happen, it will return early if such cache already exists.
>> 4) Yes.
>> 5) Good question, I will have to check that. Still I won't rely on that
>> and just always have this configuration around.
>> 6) See above about the '*'.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> сб, 25 авг. 2018 г. в 0:55, Dave Harvey :
>>
>>> I found what I've read in this area confusing, and here is my current
>>> understanding.
>>>
>>> When creating an IgniteConfiguration in Java or XML, I can specify the
>>> property cacheConfiguration, which is an array of CacheConfigurations.
>>> This causes Ignite to preserve these configurations, but this will not
>>> cause Ignite to create a cache. If I call
>>> Ignite.getOrCreateCache(string), if there is an existing cache, I will get
>>> that, otherwise a new cache will be created using that configuration.
>>>
>>> It seems like creating a cache with a configuration will add to this
>>> list, because Ignite.configuration.getCacheConfiguration() returns all
>>> caches.
>>>
>>> I can later call Ignite.addCacheConfiguration(). This will add a
>>> template to that list.
>>>
>>> Questions:
>>> 1)  what happens if there are entries with duplicate names on
>>> IgniteConfiguration.setCacheConfiguration()   when this is used to create a
>>> grid?
>>> 2) There was mention in one e-mail talking about a convention where
>>> templates have "*" in their name?
>>> 3) What happens if addCacheConfiguration() tries to add a duplicate name?
>>> 4) Is a template simply a cache that not fully instantiated?
>>> 5) What about template persistence?   Are they persisted if they specify
>>> a region that is persistent?
>>> 6) My use case is that I want to create caches based some default for
>>> the cluster, so in Java I would like to construct the new configuration
>>> from the a template of a known name.   So far, I can only see that I can
>>> call Ignite.configuration.getCacheConfiguration() and then search the array
>>> for a matching name.   Is there a better way?
>>>
>>>
>>> *Disclaimer*
>>>
>>> The information contained in this communication from the sender is
>>> confidential. It is intended solely for use by the recipient and others
>>> authorized to receive it. If you are not the recipient, you are hereby
>>> notified that any disclosure, copying, distribution or taking action in
>>> relation of the contents of this information is strictly prohibited and may
>>> be unlawful.
>>>
>>> This email has been scanned for viruses and malware, and may have been
>>> automatically archived by *Mimecast Ltd*, an innovator in Software as a
>>> Service (SaaS) for business. Providing a *safer* and *more useful*
>>> place for your human generated data. Specializing in; Security, archiving
>>> and compliance. To find out more Click Here
>>> .
>>>
>>
>
>
> *Disclaimer*
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking 

Re: Cache Configuration Templates

[Dave Harvey]

I did a suggested edit adding the Spring configuration of templates.The
rest of the current semantics seem a bit odd, so I was somewhat at a loss
as to what to write.

The wildcard approach means that I have to know the structure of the cache
name a priori.   Seems like there should be a Java API that is equivalent
to CREATE TABLE with allows a cache to be created from an arbitrary
template name, as well as a way to retrieve a copy of the
CacheConfiguration from a template name, so that it can subsequently be
enhanced.  I would assume that Ignite.cache(templateName) would fail if
the template name has a "*" in it, and instantiate a cache otherwise.

On Mon, Aug 27, 2018 at 7:31 AM, Ilya Kasnacheev 
wrote:

> Hello!
>
> Unfortunately, cache templates are not documented that good. AFAIK they
> were mostly implemented to be able to reference to complex cache
> configurations with CREATE TABLE.
>
> As far as my understanding goes, caches from cacheConfigurations are
> actually started when grid starts.
>
> 1) I think that only the first one will be used to create a cache. Even if
> you join a node with distinct cacheConfigurations to the cluster, and it
> already has some caches started, those will just be re-used (by name).
> 2) Yes, you can have a cacheConfiguration with name "prefix*", which will
> lead to a) not starting this cache on grid start, and b) when you start a
> cache "prefix1" it will use configuration from template. There's a test for
> it named IgniteCacheConfigurationTemplateTest in code base.
> 3) Nothing will happen, it will return early if such cache already exists.
> 4) Yes.
> 5) Good question, I will have to check that. Still I won't rely on that
> and just always have this configuration around.
> 6) See above about the '*'.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> сб, 25 авг. 2018 г. в 0:55, Dave Harvey :
>
>> I found what I've read in this area confusing, and here is my current
>> understanding.
>>
>> When creating an IgniteConfiguration in Java or XML, I can specify the
>> property cacheConfiguration, which is an array of CacheConfigurations.
>> This causes Ignite to preserve these configurations, but this will not
>> cause Ignite to create a cache. If I call Ignite.getOrCreateCache(string),
>> if there is an existing cache, I will get that, otherwise a new cache will
>> be created using that configuration.
>>
>> It seems like creating a cache with a configuration will add to this
>> list, because Ignite.configuration.getCacheConfiguration() returns all
>> caches.
>>
>> I can later call Ignite.addCacheConfiguration(). This will add a
>> template to that list.
>>
>> Questions:
>> 1)  what happens if there are entries with duplicate names on
>> IgniteConfiguration.setCacheConfiguration()   when this is used to
>> create a grid?
>> 2) There was mention in one e-mail talking about a convention where
>> templates have "*" in their name?
>> 3) What happens if addCacheConfiguration() tries to add a duplicate name?
>> 4) Is a template simply a cache that not fully instantiated?
>> 5) What about template persistence?   Are they persisted if they specify
>> a region that is persistent?
>> 6) My use case is that I want to create caches based some default for
>> the cluster, so in Java I would like to construct the new configuration
>> from the a template of a known name.   So far, I can only see that I can
>> call Ignite.configuration.getCacheConfiguration() and then search the
>> array for a matching name.   Is there a better way?
>>
>>
>> *Disclaimer*
>>
>> The information contained in this communication from the sender is
>> confidential. It is intended solely for use by the recipient and others
>> authorized to receive it. If you are not the recipient, you are hereby
>> notified that any disclosure, copying, distribution or taking action in
>> relation of the contents of this information is strictly prohibited and may
>> be unlawful.
>>
>> This email has been scanned for viruses and malware, and may have been
>> automatically archived by *Mimecast Ltd*, an innovator in Software as a
>> Service (SaaS) for business. Providing a *safer* and *more useful* place
>> for your human generated data. Specializing in; Security, archiving and
>> compliance. To find out more Click Here
>> .
>>
>

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast Ltd, an innovator in Software as a Service 
(SaaS) for business. Providing a safer and more useful place for your human 
generated data. Specializing in; Security, archiving and 

Re: Cache Configuration Templates

[Ilya Kasnacheev]

Hello!

Unfortunately, cache templates are not documented that good. AFAIK they
were mostly implemented to be able to reference to complex cache
configurations with CREATE TABLE.

As far as my understanding goes, caches from cacheConfigurations are
actually started when grid starts.

1) I think that only the first one will be used to create a cache. Even if
you join a node with distinct cacheConfigurations to the cluster, and it
already has some caches started, those will just be re-used (by name).
2) Yes, you can have a cacheConfiguration with name "prefix*", which will
lead to a) not starting this cache on grid start, and b) when you start a
cache "prefix1" it will use configuration from template. There's a test for
it named IgniteCacheConfigurationTemplateTest in code base.
3) Nothing will happen, it will return early if such cache already exists.
4) Yes.
5) Good question, I will have to check that. Still I won't rely on that and
just always have this configuration around.
6) See above about the '*'.

Regards,
-- 
Ilya Kasnacheev


сб, 25 авг. 2018 г. в 0:55, Dave Harvey :

> I found what I've read in this area confusing, and here is my current
> understanding.
>
> When creating an IgniteConfiguration in Java or XML, I can specify the
> property cacheConfiguration, which is an array of CacheConfigurations.
> This causes Ignite to preserve these configurations, but this will not
> cause Ignite to create a cache. If I call
> Ignite.getOrCreateCache(string), if there is an existing cache, I will get
> that, otherwise a new cache will be created using that configuration.
>
> It seems like creating a cache with a configuration will add to this list,
> because Ignite.configuration.getCacheConfiguration() returns all caches.
>
>
> I can later call Ignite.addCacheConfiguration(). This will add a template
> to that list.
>
> Questions:
> 1)  what happens if there are entries with duplicate names on
> IgniteConfiguration.setCacheConfiguration()   when this is used to create a
> grid?
> 2) There was mention in one e-mail talking about a convention where
> templates have "*" in their name?
> 3) What happens if addCacheConfiguration() tries to add a duplicate name?
> 4) Is a template simply a cache that not fully instantiated?
> 5) What about template persistence?   Are they persisted if they specify a
> region that is persistent?
> 6) My use case is that I want to create caches based some default for the
> cluster, so in Java I would like to construct the new configuration from
> the a template of a known name.   So far, I can only see that I can call
> Ignite.configuration.getCacheConfiguration() and then search the array for
> a matching name.   Is there a better way?
>
>
> *Disclaimer*
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by *Mimecast Ltd*, an innovator in Software as a
> Service (SaaS) for business. Providing a *safer* and *more useful* place
> for your human generated data. Specializing in; Security, archiving and
> compliance. To find out more Click Here
> .
>

Cache Configuration Templates

[Dave Harvey]

I found what I've read in this area confusing, and here is my current
understanding.

When creating an IgniteConfiguration in Java or XML, I can specify the
property cacheConfiguration, which is an array of CacheConfigurations.
This causes Ignite to preserve these configurations, but this will not
cause Ignite to create a cache. If I call Ignite.getOrCreateCache(string),
if there is an existing cache, I will get that, otherwise a new cache will
be created using that configuration.

It seems like creating a cache with a configuration will add to this list,
because Ignite.configuration.getCacheConfiguration() returns all caches.

I can later call Ignite.addCacheConfiguration(). This will add a template
to that list.

Questions:
1)  what happens if there are entries with duplicate names on
IgniteConfiguration.setCacheConfiguration()   when this is used to create a
grid?
2) There was mention in one e-mail talking about a convention where
templates have "*" in their name?
3) What happens if addCacheConfiguration() tries to add a duplicate name?
4) Is a template simply a cache that not fully instantiated?
5) What about template persistence?   Are they persisted if they specify a
region that is persistent?
6) My use case is that I want to create caches based some default for the
cluster, so in Java I would like to construct the new configuration from
the a template of a known name.   So far, I can only see that I can call
Ignite.configuration.getCacheConfiguration() and then search the array for
a matching name.   Is there a better way?

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast Ltd, an innovator in Software as a Service 
(SaaS) for business. Providing a safer and more useful place for your human 
generated data. Specializing in; Security, archiving and compliance. To find 
out more visit the Mimecast website.