Pavel,
"deprecate" != "delete" or "brake". We are not going to wait for 3.0. New
SQL should be designed carefully taking as mush current and future features
in count as possible. That said, in order to add new concepts like
"constraint" on PAI level we should at least start separate discussion and
> QueryEntity is already too complex
> let's make it even more complex
We already see that String-based approach is bad:
* LinkedHashMap fields
* Set keyFields
* Map aliases
Which should have been just QueryField { name, isKey, alias }.
Let's learn from our mistakes and do constraints right.
>
Guys,
QueryEntity is already too complex. We will deprecate it soon in favor of
brand new SQL API. No need to design FieldConstraint or something similar
at the moment, let's just stick to "Set notNullFields".
On Fri, Jul 21, 2017 at 7:08 PM, Sergey Chugunov
wrote:
> Sergey,
>
> It may be a goo
Sergey,
It may be a good idea to distinguish between field constraints (like "not
null" one) which can be applied to only one field; and more complex
constraints that involves more than one field.
In case of field constraints it is better to simplify our model and allow
only one field to appear i
Sergey, looks good to me!
I thought of something a bit different, where there is a base class
and each constraint type inherits it, but your design is actually better.
Pavel
On Fri, Jul 21, 2017 at 6:38 PM, Sergey Kalashnikov
wrote:
> Hi Pavel,
>
> Good point! What if we make it the following
Hi Pavel,
Good point! What if we make it the following way?
class QueryEntity {
...
/** All constraints to be enforced on this QueryEntity. */
Set constraint;
}
/** Describes constraints that affect one or more fields. */
class QueryConstraint {
/** Names of fields to be checked
Hi Sergey,
This one looks not very good to me:
> class QueryEntity {
> ...
> Set notNullFields;
> }
What if there are more constraints in future? UNIQUE, CHECK, etc etc?
Instead we could do something like
Set constraints;
Which is easily extendable in future.
Thoughts?
Pavel
On
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
> wrote:
>
> Hi Igniters,
>
> I am workin
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,
Denis Magda created IGNITE-5648:
---
Summary: NOT NULL constraint support for CREATE TABLE operator
Key: IGNITE-5648
URL: https://issues.apache.org/jira/browse/IGNITE-5648
Project: Ignite
Issue
10 matches
Mail list logo
