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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> >>> 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 >>>> >>>> >>>> >> >> >
