Vladimir,

I fully agree. We don't expose groups to public API (except for cache configuration), so we shouldn't start doing it here.

Ignite issue for this improvement: https://issues.apache.org/jira/browse/IGNITE-8473

Best Regards,
Ivan Rakov

On 11.05.2018 17:49, Vladimir Ozerov wrote:
Ivan,

WAL disable for multiple caches was not implemented in the first place for
a reason. We striven to maintain API consistency,
"IgniteCluster.disableWal(cacheName)" maps exactly to "ALTER TABLE
tableName NOLOGGING" command.  There is no SQL equivalent for multiple
caches. WAL disable for multiple tables is typically handled through
tablespace which is an arbitrary logical group of objects sharing the same
physical files. We have only cache group notion which is a set of tables
with the same backup and affinity properties sharing the same files. As I
hope we would replace groups with tablespaces my preference is not to
expose any SQL commands for cache groups. Neither I would expose cache
groups to public API unless absolutely needed.

I would suggest to extend native API with a command accepting multiple
cache names, not cache groups:

IgniteCluster.disableWal(Collection<String> cacheNames)
IgniteCluster.enableWal(Collection<String> cacheNames)

Makes sense?

Vladimir.

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



Reply via email to