Thx! On Aug 9, 2015 11:15 PM, "Ildar Absalyamov" <[email protected]> wrote:
> It is used to deserialize the proper type, however this is needed only in > open index case. > I get around by avoiding storing any type-related information in the index > metadata, unless it is opened. In closed case the type would be picked > from the record metadata, thus getting nullability information and not > replicating it anywhere. > I created an uploaded a new patch set, feel free to check and prove it if > everything else is OK. > > > On Aug 9, 2015, at 00:54, Mike Carey <[email protected]> wrote: > > > > Q: Is the nullability info drawn from the index entry really used? Can > you give an example of where/how? (Wondering if it's perhaps removable.) > > > > On 8/7/15 2:39 PM, Ildar Absalyamov wrote: > >> So it turned out I was wrong about about open indexes & nullable types. > Is > >> is indeed not allowed that, is you look closely on parser's production > rules > >> The problem appears when we're trying to create an ordinary index on > >> nullable field. The information about the field type is persisted in the > >> index metadata entry. In the open case the type is provided by the user, > >> whereas in the closed the type is extracted from the record's metadata > >> entry (where we do have a nullability attribute). We can replicate the > >> nullablility attribute in the index metadata entry as well, but I think > >> that is against the Till's original comment since this information is > >> becoming spread around several places. Other solution would be to carry > "if > >> (open) {} else if (closed) {}" logic throughout the code, where we do > need > >> nullability information, but that will be ugly. > >> > >> 2015-08-07 11:18 GMT-07:00 Michael Carey <[email protected]>: > >> > >>> Q: (@Ildar) - What's the status of removing "?" from the open index DDL > >>> and reverting that (unnecessary) part of the metadata patch? > >>> > >> > >> > > > > Best regards, > Ildar > >
