Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
From: Sergey Kalashnikov <zkillingjar@gmail.com>
Date: Thu, 20 Jul 2017 22:27:45 +0300
Message-ID: <CAJqxj7ETM6nh42Bta-rUhFg5eQwO+qbjVxkFs+OgGnKGYoQdbQ@mail.gmail.com>
Subject: "not null" constraint support
To: dev@ignite.apache.org
Content-Type: text/plain; charset="UTF-8"
archived-at: Thu, 20 Jul 2017 19:27:52 -0000

Hi Igniters,

I am working on the ticket
https://issues.apache.org/jira/browse/IGNITE-5648, which purpose is to
add support for NOT NULL constraint for any fields of key or value
stored in Ignite cache.

I would appreciate your comments on the design approach I have described below.

In my opinion, such checks should be enforced both by SQL DML and
cache API to be consistent.

Here is my analysis of what needs to be done.

1. First, the SQL CREATE table will not throw exception anymore
whenever it encounters a column with "not null" modifier.
Instead, the resulting QueryEntity will now indicate which fields have
such modifier.

The proposed way of doing this is the following:
class QueryEntity {
    ...
    Set<String> notNullFields;
}

Since QueryEntity is a part of public api, it becomes possible to
configure this constraint not only via DDL CREATE TABLE.

2. Then we need a special method on GridQueryProcessor that for the
given cacheName, key and value would perform the following things:
- Get a GridQueryTypeDescriptor that corresponds to given value type;
- Delegate that GridQueryTypeDescriptor a task to validate given key and value;
- Type descriptor would itself delegate the validation to its
GridQueryProperties that have "not null" constraint.

3. To enforce the constraints, the validation method should be called
- In GridNearAtomicSingleUpdateFuture.mapSingleUpdate() and
GridNearAtomicUpdateFuture.mapUpdate() when operation is CREATE or
UPDATE.
That would cover putIfAbsent(), getAndPut(), getAndPutIfAbsent(),
replace(), getAndReplace(), putAll() operations on atomic cache.
And in GridNearTxLocal.enlistWriteEntry() when operation is CREATE or
UPDATE for the case of transactional cache.

- Right after EntryProcessor.process() in
GridCacheMapEntry.AtomicCacheUpdateClosure.runEntryProcessor() as part
of invoke(), invokeAll() operations on atomic cache.
And in GridDhtTxPrepareFuture.onEntriesLocked() for the case of
transactional cache.

4. DML processor changes
  The DMLStatementProcessor methods doInsert(), doUpdate(), doMerge()
must also incorporate such checks to avoid attempts
  to insert values that are known to be rejected by cache.

Thoughts?

--
Best regards,
Sergey