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
