Configuring Cassandra persistence from code

[Valentin Kulichenko]

Hi Igor,

I just noticed that KeyValuePersistenceSettings class required to configure
Cassandra store can be created only based on XML file of a special format.

If so, this looks like a pretty serious limitation. First of all, when
configuring such cache, user has to know both Spring configuration format
and this specific format for persistence. In other words, persistence
configuration seems to be weirdly separated from all other configurations
in a separate file with a different format.

But most importantly, what if user wants to create a cache dynamically and
doesn't know configuration in advance? How are they supposed to create this
special XML in this case?

Is my understanding correct? If so, I think we should add standard getters
and setters to KeyValuePersistenceSettings. This will make it compatible
with Spring and will allow to create it dynamically in code.

Agree?

-Val

[irudyak]

Good question. The main case for this getters/setters API is when you are
going to dynamically create Cassandra persistence configuration for you
cache.

As I see it, in most cases developers will create kind of xml persistent
descriptor template, which will be used to generate final persistence
descriptor for particular cache or just reuse already existing persistence
descriptor. In case you want to generate persistence descritor dynamically
from scratch I don't see much difference from doing it using
getters/setters API or generating XML document - in both cases it will be
lot's of XML API or Persistence Descriptor API calls.

Any thoughts?


On Jan 12, 2017 3:36 PM, "Valentin Kulichenko" <
[hidden email]> wrote:

> Hi Igor,
>
> I just noticed that KeyValuePersistenceSettings class required to
> configure Cassandra store can be created only based on XML file of a
> special format.
>
> If so, this looks like a pretty serious limitation. First of all, when
> configuring such cache, user has to know both Spring configuration format
> and this specific format for persistence. In other words, persistence
> configuration seems to be weirdly separated from all other configurations
> in a separate file with a different format.
>
> But most importantly, what if user wants to create a cache dynamically and
> doesn't know configuration in advance? How are they supposed to create this
> special XML in this case?
>
> Is my understanding correct? If so, I think we should add standard getters
> and setters to KeyValuePersistenceSettings. This will make it compatible
> with Spring and will allow to create it dynamically in code.
>
> Agree?
>
> -Val
>

[Valentin Kulichenko]

Hi Igor,

Why did you choose to use a special format instead of going with Spring in
the first place? It seems to that this is what creating difficulties here,
because with Spring any of scenarios we mentioned is possible:

   - You can create a template in XML, load it using
   Ignition.loadSpringBean() and modify in code.
   - You can provide full configuration in the same file where Ignite
   configuration is.
   - You can configure everything in code if you don't like XML.

Current approach seems to introduce too many limitations to be usable. Do
you have any objections against making KeyValuePersistenceSettings class
Spring compatible? If not, I will create a ticket. Or maybe you have other
suggestions on how to improve flexibility here?

-Val

On Thu, Jan 12, 2017 at 6:09 PM, Igor Rudyak <[hidden email]> wrote:

> Good question. The main case for this getters/setters API is when you are
> going to dynamically create Cassandra persistence configuration for you
> cache.
>
> As I see it, in most cases developers will create kind of xml persistent
> descriptor template, which will be used to generate final persistence
> descriptor for particular cache or just reuse already existing persistence
> descriptor. In case you want to generate persistence descritor dynamically
> from scratch I don't see much difference from doing it using
> getters/setters API or generating XML document - in both cases it will be
> lot's of XML API or Persistence Descriptor API calls.
>
> Any thoughts?
>
>
> On Jan 12, 2017 3:36 PM, "Valentin Kulichenko" <
> [hidden email]> wrote:
>
>> Hi Igor,
>>
>> I just noticed that KeyValuePersistenceSettings class required to
>> configure Cassandra store can be created only based on XML file of a
>> special format.
>>
>> If so, this looks like a pretty serious limitation. First of all, when
>> configuring such cache, user has to know both Spring configuration format
>> and this specific format for persistence. In other words, persistence
>> configuration seems to be weirdly separated from all other configurations
>> in a separate file with a different format.
>>
>> But most importantly, what if user wants to create a cache dynamically
>> and doesn't know configuration in advance? How are they supposed to create
>> this special XML in this case?
>>
>> Is my understanding correct? If so, I think we should add standard
>> getters and setters to KeyValuePersistenceSettings. This will make it
>> compatible with Spring and will allow to create it dynamically in code.
>>
>> Agree?
>>
>> -Val
>>
>

[irudyak]

Hi Val,

The main reason why Spring wasn't utilized, is to support Ignite-Cassandra
integration without using Spring. As you know, Spring is not required
component to run Ignite. Thus the main idea to avoid Spring was to provide
Cassandra integration for Spring-less Ignite environments.

Igor

On Fri, Jan 13, 2017 at 11:37 AM, Valentin Kulichenko <
[hidden email]> wrote:

> Hi Igor,
>
> Why did you choose to use a special format instead of going with Spring in
> the first place? It seems to that this is what creating difficulties here,
> because with Spring any of scenarios we mentioned is possible:
>
>    - You can create a template in XML, load it using
>    Ignition.loadSpringBean() and modify in code.
>    - You can provide full configuration in the same file where Ignite
>    configuration is.
>    - You can configure everything in code if you don't like XML.
>
> Current approach seems to introduce too many limitations to be usable. Do
> you have any objections against making KeyValuePersistenceSettings class
> Spring compatible? If not, I will create a ticket. Or maybe you have other
> suggestions on how to improve flexibility here?
>
> -Val
>
> On Thu, Jan 12, 2017 at 6:09 PM, Igor Rudyak <[hidden email]> wrote:
>
>> Good question. The main case for this getters/setters API is when you are
>> going to dynamically create Cassandra persistence configuration for you
>> cache.
>>
>> As I see it, in most cases developers will create kind of xml persistent
>> descriptor template, which will be used to generate final persistence
>> descriptor for particular cache or just reuse already existing persistence
>> descriptor. In case you want to generate persistence descritor dynamically
>> from scratch I don't see much difference from doing it using
>> getters/setters API or generating XML document - in both cases it will be
>> lot's of XML API or Persistence Descriptor API calls.
>>
>> Any thoughts?
>>
>>
>> On Jan 12, 2017 3:36 PM, "Valentin Kulichenko" <
>> [hidden email]> wrote:
>>
>>> Hi Igor,
>>>
>>> I just noticed that KeyValuePersistenceSettings class required to
>>> configure Cassandra store can be created only based on XML file of a
>>> special format.
>>>
>>> If so, this looks like a pretty serious limitation. First of all, when
>>> configuring such cache, user has to know both Spring configuration format
>>> and this specific format for persistence. In other words, persistence
>>> configuration seems to be weirdly separated from all other configurations
>>> in a separate file with a different format.
>>>
>>> But most importantly, what if user wants to create a cache dynamically
>>> and doesn't know configuration in advance? How are they supposed to create
>>> this special XML in this case?
>>>
>>> Is my understanding correct? If so, I think we should add standard
>>> getters and setters to KeyValuePersistenceSettings. This will make it
>>> compatible with Spring and will allow to create it dynamically in code.
>>>
>>> Agree?
>>>
>>> -Val
>>>
>>
>

[Valentin Kulichenko]

Igor,

I'm not against existing functionality and definitely do not propose to rip
and replace it. However, while Spring is not required, it's used in vast
majority of cases to configure Ignite.

Having said that, I think this an important usability improvement. Here is
the ticket: https://issues.apache.org/jira/browse/IGNITE-4555

-Val

On Sun, Jan 15, 2017 at 7:40 PM, Igor Rudyak <[hidden email]> wrote:

> Hi Val,
>
> The main reason why Spring wasn't utilized, is to support Ignite-Cassandra
> integration without using Spring. As you know, Spring is not required
> component to run Ignite. Thus the main idea to avoid Spring was to provide
> Cassandra integration for Spring-less Ignite environments.
>
> Igor
>
> On Fri, Jan 13, 2017 at 11:37 AM, Valentin Kulichenko <
> [hidden email]> wrote:
>
>> Hi Igor,
>>
>> Why did you choose to use a special format instead of going with Spring
>> in the first place? It seems to that this is what creating difficulties
>> here, because with Spring any of scenarios we mentioned is possible:
>>
>>    - You can create a template in XML, load it using
>>    Ignition.loadSpringBean() and modify in code.
>>    - You can provide full configuration in the same file where Ignite
>>    configuration is.
>>    - You can configure everything in code if you don't like XML.
>>
>> Current approach seems to introduce too many limitations to be usable. Do
>> you have any objections against making KeyValuePersistenceSettings class
>> Spring compatible? If not, I will create a ticket. Or maybe you have other
>> suggestions on how to improve flexibility here?
>>
>> -Val
>>
>> On Thu, Jan 12, 2017 at 6:09 PM, Igor Rudyak <[hidden email]> wrote:
>>
>>> Good question. The main case for this getters/setters API is when you
>>> are going to dynamically create Cassandra persistence configuration for you
>>> cache.
>>>
>>> As I see it, in most cases developers will create kind of xml persistent
>>> descriptor template, which will be used to generate final persistence
>>> descriptor for particular cache or just reuse already existing persistence
>>> descriptor. In case you want to generate persistence descritor dynamically
>>> from scratch I don't see much difference from doing it using
>>> getters/setters API or generating XML document - in both cases it will be
>>> lot's of XML API or Persistence Descriptor API calls.
>>>
>>> Any thoughts?
>>>
>>>
>>> On Jan 12, 2017 3:36 PM, "Valentin Kulichenko" <
>>> [hidden email]> wrote:
>>>
>>>> Hi Igor,
>>>>
>>>> I just noticed that KeyValuePersistenceSettings class required to
>>>> configure Cassandra store can be created only based on XML file of a
>>>> special format.
>>>>
>>>> If so, this looks like a pretty serious limitation. First of all, when
>>>> configuring such cache, user has to know both Spring configuration format
>>>> and this specific format for persistence. In other words, persistence
>>>> configuration seems to be weirdly separated from all other configurations
>>>> in a separate file with a different format.
>>>>
>>>> But most importantly, what if user wants to create a cache dynamically
>>>> and doesn't know configuration in advance? How are they supposed to create
>>>> this special XML in this case?
>>>>
>>>> Is my understanding correct? If so, I think we should add standard
>>>> getters and setters to KeyValuePersistenceSettings. This will make it
>>>> compatible with Spring and will allow to create it dynamically in code.
>>>>
>>>> Agree?
>>>>
>>>> -Val
>>>>
>>>
>>
>

[irudyak]

Ok, makes sense.

Igor

On Tue, Jan 17, 2017 at 3:25 PM, Valentin Kulichenko <
[hidden email]> wrote:

> Igor,
>
> I'm not against existing functionality and definitely do not propose to
> rip and replace it. However, while Spring is not required, it's used in
> vast majority of cases to configure Ignite.
>
> Having said that, I think this an important usability improvement. Here is
> the ticket: https://issues.apache.org/jira/browse/IGNITE-4555
>
> -Val
>
> On Sun, Jan 15, 2017 at 7:40 PM, Igor Rudyak <[hidden email]> wrote:
>
>> Hi Val,
>>
>> The main reason why Spring wasn't utilized, is to support
>> Ignite-Cassandra integration without using Spring. As you know, Spring is
>> not required component to run Ignite. Thus the main idea to avoid Spring
>> was to provide Cassandra integration for Spring-less Ignite environments.
>>
>> Igor
>>
>> On Fri, Jan 13, 2017 at 11:37 AM, Valentin Kulichenko <
>> [hidden email]> wrote:
>>
>>> Hi Igor,
>>>
>>> Why did you choose to use a special format instead of going with Spring
>>> in the first place? It seems to that this is what creating difficulties
>>> here, because with Spring any of scenarios we mentioned is possible:
>>>
>>>    - You can create a template in XML, load it using
>>>    Ignition.loadSpringBean() and modify in code.
>>>    - You can provide full configuration in the same file where Ignite
>>>    configuration is.
>>>    - You can configure everything in code if you don't like XML.
>>>
>>> Current approach seems to introduce too many limitations to be usable.
>>> Do you have any objections against making KeyValuePersistenceSettings class
>>> Spring compatible? If not, I will create a ticket. Or maybe you have other
>>> suggestions on how to improve flexibility here?
>>>
>>> -Val
>>>
>>> On Thu, Jan 12, 2017 at 6:09 PM, Igor Rudyak <[hidden email]> wrote:
>>>
>>>> Good question. The main case for this getters/setters API is when you
>>>> are going to dynamically create Cassandra persistence configuration for you
>>>> cache.
>>>>
>>>> As I see it, in most cases developers will create kind of xml
>>>> persistent descriptor template, which will be used to generate final
>>>> persistence descriptor for particular cache or just reuse already existing
>>>> persistence descriptor. In case you want to generate persistence descritor
>>>> dynamically from scratch I don't see much difference from doing it using
>>>> getters/setters API or generating XML document - in both cases it will be
>>>> lot's of XML API or Persistence Descriptor API calls.
>>>>
>>>> Any thoughts?
>>>>
>>>>
>>>> On Jan 12, 2017 3:36 PM, "Valentin Kulichenko" <
>>>> [hidden email]> wrote:
>>>>
>>>>> Hi Igor,
>>>>>
>>>>> I just noticed that KeyValuePersistenceSettings class required to
>>>>> configure Cassandra store can be created only based on XML file of a
>>>>> special format.
>>>>>
>>>>> If so, this looks like a pretty serious limitation. First of all, when
>>>>> configuring such cache, user has to know both Spring configuration format
>>>>> and this specific format for persistence. In other words, persistence
>>>>> configuration seems to be weirdly separated from all other configurations
>>>>> in a separate file with a different format.
>>>>>
>>>>> But most importantly, what if user wants to create a cache dynamically
>>>>> and doesn't know configuration in advance? How are they supposed to create
>>>>> this special XML in this case?
>>>>>
>>>>> Is my understanding correct? If so, I think we should add standard
>>>>> getters and setters to KeyValuePersistenceSettings. This will make it
>>>>> compatible with Spring and will allow to create it dynamically in code.
>>>>>
>>>>> Agree?
>>>>>
>>>>> -Val
>>>>>
>>>>
>>>
>>
>