ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Rudyak <irud...@gmail.com>
Subject Re: Configuring Cassandra persistence from code
Date Wed, 18 Jan 2017 01:37:05 GMT
Ok, makes sense.


On Tue, Jan 17, 2017 at 3:25 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> 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 <irudyak@gmail.com> 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 <
>> valentin.kulichenko@gmail.com> 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 <irudyak@gmail.com> 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" <
>>>> valentin.kulichenko@gmail.com> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message