Re: QueryEntity design

2018-03-07 Thread Vladimir Ozerov 
I do not think it is a big problem. We copy these values when starting node
anyway, so subsequent changes doesn't affect node's behavior. On the other
hand, this might be convenient to users in some cases.

On Wed, Mar 7, 2018 at 3:13 PM, Nikolay Izhikov  wrote:

> Vladimir.
>
> Thank you, it's clear now.
>
> I also wonder, why we provide access to internal HashMaps through getters?
> Should we wrap internal maps into `Collections.unmodifiableMap`?
>
>
> ```
> public Map getDefaultFieldValues() {
> return defaultFieldValues;
> }
> ```
>
> В Ср, 07/03/2018 в 14:36 +0300, Vladimir Ozerov пишет:
> > Hi Nikolay,
> >
> > The answer is simple - legacy. QueryEntity was introduced long before we
> > had rich SQL support. At this point we should consider both QueryEntity
> and
> > our SQL API obsolete. There is a ticket to design new SQL API [1] and new
> > "QueryEntity" should be it's integral part. If you have any ideas please
> > feel free to share.
> >
> > Vladimir.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-4701
> >
> > On Wed, Mar 7, 2018 at 2:00 PM, Nikolay Izhikov 
> wrote:
> >
> > > Hello, Igniters.
> > >
> > > I'm working on IGNITE-7691 [1]
> > > The goal of ticket is provide scale and precision info about DECIMAL
> > > columns.
> > >
> > > I see that QueryEntity has a separate collection for each type of meta
> > > information:
> > >
> > > * not null fields - [2]
> > > * default values - [3]
> > >
> > > Why we have such class design?
> > > It seems like a wrong design to have a separate collection for every
> type
> > > of metainfo.
> > >
> > > Because, there are many pieces of column meta information:
> > >
> > > * not null
> > > * default value
> > > * maximum length/size for VARCHAR or ARRAY or BINARY
> > > * scale, precision
> > > * etc.
> > >
> > > Do we have plans to provide this information to user through
> QueryEntity?
> > >
> > > [1] https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-7691
> > > [2] https://github.com/apache/ignite/blob/master/modules/
> > > core/src/main/java/org/apache/ignite/cache/QueryEntity.java#L87
> > > [3] https://github.com/apache/ignite/blob/master/modules/
> > > core/src/main/java/org/apache/ignite/cache/QueryEntity.java#L90
>

Re: QueryEntity design

2018-03-07 Thread Nikolay Izhikov 
Vladimir.

Thank you, it's clear now.

I also wonder, why we provide access to internal HashMaps through getters?
Should we wrap internal maps into `Collections.unmodifiableMap`?


```
public Map getDefaultFieldValues() {
return defaultFieldValues;
}
```

В Ср, 07/03/2018 в 14:36 +0300, Vladimir Ozerov пишет:
> Hi Nikolay,
> 
> The answer is simple - legacy. QueryEntity was introduced long before we
> had rich SQL support. At this point we should consider both QueryEntity and
> our SQL API obsolete. There is a ticket to design new SQL API [1] and new
> "QueryEntity" should be it's integral part. If you have any ideas please
> feel free to share.
> 
> Vladimir.
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-4701
> 
> On Wed, Mar 7, 2018 at 2:00 PM, Nikolay Izhikov  wrote:
> 
> > Hello, Igniters.
> > 
> > I'm working on IGNITE-7691 [1]
> > The goal of ticket is provide scale and precision info about DECIMAL
> > columns.
> > 
> > I see that QueryEntity has a separate collection for each type of meta
> > information:
> > 
> > * not null fields - [2]
> > * default values - [3]
> > 
> > Why we have such class design?
> > It seems like a wrong design to have a separate collection for every type
> > of metainfo.
> > 
> > Because, there are many pieces of column meta information:
> > 
> > * not null
> > * default value
> > * maximum length/size for VARCHAR or ARRAY or BINARY
> > * scale, precision
> > * etc.
> > 
> > Do we have plans to provide this information to user through QueryEntity?
> > 
> > [1] https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-7691
> > [2] https://github.com/apache/ignite/blob/master/modules/
> > core/src/main/java/org/apache/ignite/cache/QueryEntity.java#L87
> > [3] https://github.com/apache/ignite/blob/master/modules/
> > core/src/main/java/org/apache/ignite/cache/QueryEntity.java#L90

signature.asc
Description: This is a digitally signed message part

Re: QueryEntity design

2018-03-07 Thread Vladimir Ozerov 
Hi Nikolay,

The answer is simple - legacy. QueryEntity was introduced long before we
had rich SQL support. At this point we should consider both QueryEntity and
our SQL API obsolete. There is a ticket to design new SQL API [1] and new
"QueryEntity" should be it's integral part. If you have any ideas please
feel free to share.

Vladimir.

[1] https://issues.apache.org/jira/browse/IGNITE-4701

On Wed, Mar 7, 2018 at 2:00 PM, Nikolay Izhikov  wrote:

> Hello, Igniters.
>
> I'm working on IGNITE-7691 [1]
> The goal of ticket is provide scale and precision info about DECIMAL
> columns.
>
> I see that QueryEntity has a separate collection for each type of meta
> information:
>
> * not null fields - [2]
> * default values - [3]
>
> Why we have such class design?
> It seems like a wrong design to have a separate collection for every type
> of metainfo.
>
> Because, there are many pieces of column meta information:
>
> * not null
> * default value
> * maximum length/size for VARCHAR or ARRAY or BINARY
> * scale, precision
> * etc.
>
> Do we have plans to provide this information to user through QueryEntity?
>
> [1] https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-7691
> [2] https://github.com/apache/ignite/blob/master/modules/
> core/src/main/java/org/apache/ignite/cache/QueryEntity.java#L87
> [3] https://github.com/apache/ignite/blob/master/modules/
> core/src/main/java/org/apache/ignite/cache/QueryEntity.java#L90