Hi Dmitry,
I tend to agree with point 1. Yes it might seem as a good to hint a
default value in a boolean propery name. But it looks flawed to me
because a default value can be changed and it will bring a mess.
Regarding point 2. The idea is good in general. But there are several
problems with mentioned traits. CacheConfiguration extends JCache
class and inherits readThrough/writeThrough methods. SQL properties
should be rethinked in a wide context. I heard ideas about introducing
new SQL API which will have query methods outside of IgniteCache,
pehaps it can make difference for SQL configuration as well. Need to
figure out how to tackle all of that.
ср, 17 апр. 2019 г. в 13:37, Dmitry Sherstobitov <
[hidden email]>:
>
> Dear Ignite developers,
>
> I have some ideas about Ignite 3.0 release and simplifications that might be included in the future release:
>
> 1. Remove *_ENABLED/*_DISABLED from Ignite system properties. I see only one advantage in this case - some information about default value: e.g. _ENABLED property is disabled by default. On the other hand, you need to know is this property ends with _ENABLED to _DISABLED. Removing these additions makes property names more clear and they will be easy to remember and use (default values could be found in search engine as before) (
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html)
> 2. Group similar properties into sub-objects in CacheConfiguration. For example, all SQL properties may be in some SQLCacheConfiguration object, writeThrough/readThrough may be in some sub-object as well. This change makes CacheConfiguration class more clear and XML cache configuration itself much easier to configure - the user has information about all properties in context and which of them are mandatory.
>
>
> Best regards,
> Dmitriy Sherstobitov
>
--
Best regards,
Ivan Pavlukhin
Locked
