ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: "not null" constraint support
Date Fri, 21 Jul 2017 07:54:54 GMT
Hi Sergey,

This one looks not very good to me:

> class QueryEntity {
>     ...
>     Set<String> notNullFields;
> }

What if there are more constraints in future? UNIQUE, CHECK, etc etc?

Instead we could do something like

    Set<QueryConstraint> constraints;

Which is easily extendable in future.

Thoughts?

Pavel

On Thu, Jul 20, 2017 at 11:17 PM, Denis Magda <dmagda@apache.org> wrote:

> 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 <zkillingjar@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message