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<String, Object> 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 <nizhi...@apache.org> 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
