Hi Sergey, That will be an excellent addition to DDL features set.
The proposed changes look good to from the public API standpoint. Alexander P., Sergi, Vovan, please share your thoughts. — Denis > On Jul 20, 2017, at 12:27 PM, Sergey Kalashnikov <zkilling...@gmail.com> > wrote: > > 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
