Agree about collections.

Regarding return type: it's a tricky question. Maybe author of this feature may help.
Anton V., in which case enableWal/disableWal can return false?

Best Regards,
Ivan Rakov

On 11.05.2018 18:19, Vladimir Ozerov wrote:
Ivan,

This proven to be too hard to understand.  It is better to have a lot small
methods with clear and compact semantics. Also arrays are harder to manage
than collections, users typically prefer the latest.
Also we need to think on what would be a result of this operation. Current
methods with a single cache return true/false based on whether they changed
something or not. Should we continue returning a single boolean for batch
operations as well?

On Fri, May 11, 2018 at 6:13 PM, Ivan Rakov <ivan.glu...@gmail.com> wrote:

It would be six methods in total (3 for enabling, 3 for disabling).
What about accepting null in *enableWAL(String... caches)* as wildcard?

Best Regards,
Ivan Rakov


On 11.05.2018 17:52, Andrey Mashenkov wrote:

Ivan,

Huge +1 for this improvement.

I think we can have 2 overloaded method enableWal() with no args to enable
WAL for all caches
and enableWAL(String... caches) for one or multiple caches. (and same for
disable wal)



On Fri, May 11, 2018 at 5:25 PM, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com> wrote:

Ivan,
Agree, if we have the batch method for cache create, we should have the
ability to enable/disable WAL in the batch too.

On Fri, May 11, 2018 at 5:17 PM, Ivan Rakov <ivan.glu...@gmail.com>
wrote:

Igniters,
API method for disabling WAL in IgniteCluster accepts only one cache

name.

Every call triggers exchange and checkpoints cluster-wide - it takes

plenty

of time to disable/enable WAL for multiple caches.
I think, we should add option to disable/enable WAL for several caches
with single command.

Thoughts?

--
Best Regards,
Ivan Rakov





Reply via email to