Cool; thx!
On 8/10/15 12:12 PM, Ildar Absalyamov wrote:
Submitted version has a regression in optimizer tests. I know what is the
issue and will fix that tonight.
2015-08-10 10:44 GMT-07:00 Mike Carey <[email protected]>:
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
