When a dataset already has a tuple, a keyword index on a list can not be created properly.If a dataset already has a tuple, a keyword index on a list can not be created properly.

[GoogleCodeExporter]

What steps will reproduce the problem?
=======================================

1.Execute the following queries
drop dataverse test if exists;

create dataverse test;
use dataverse test;

create type TopicType as closed {
        name: string,
        aliases: {{ string }},
        url: string
}

drop dataset Entities if exists;
create dataset Entities(TopicType) primary key url;
create index topicNameIdx on Entities(name) type keyword;

// Now, let's try to insert a record. If you create an index before inserting a 
tuple, it's OK
// If you create the following index after inserting a tuple, it generates an 
error - null []  

insert into dataset Entities ({"aliases":{{"abc","ABC"}},"name":"A B 
C","url":"A_B_C"});
create index aliasesIdx on Entities(aliases) type keyword;

What is the expected output? What do you see instead?
===============================
I should see OK. Instead, null [] is printed. 

Original issue reported on code.google.com by wangs...@gmail.com on 22 Oct 2014 at 9:48

• Merged into: #419

[GoogleCodeExporter]

I think there is a related issue here while trying to load this attached ADM 
file. It results in a ArrayIndexOutOfBounds in the logs during Inverted Index 
bulk-load, caused by FixedSizeElementInvertedListBuilder being fed a ITypeTrait 
that is not of fixed size. 

Original comment by ima...@uci.edu on 4 Nov 2014 at 11:48

• Changed title: _When a dataset already has a tuple, a keyword index on a list can not be created properly.If a dataset already has a tuple, a keyword index on a list can not be created properly. _

Attachments:

• topics.adm

[GoogleCodeExporter]

This appears to be a duplicate of 419 (note that the primary key is on url, a 
string field). The error message definitely does not suggest one should not be 
able to do this; it is only implied on inspecting the loading code that one 
discovers things go awry once a variable-length type is used to construct the 
inverted index. 

Original comment by ima...@uci.edu on 5 Nov 2014 at 2:46

• Changed state: Duplicate

[GoogleCodeExporter]

Sounds like it's simply a matter of better checking at index create time, then, 
to statically reject these cases with an understandable / apologetic error 
message.  (And we should open a future feature request to un-restrict this, 
maybe future work for Taewoo or Young-Seok who will be in that part of the code 
for awhile in the future.

Original comment by dtab...@gmail.com on 5 Nov 2014 at 9:41

[GoogleCodeExporter]

Agreed on future work. Meanwhile, I will put the check routine (creating an 
inverted index where the schema has the variable-length primary key) when 
creating an index. 

Original comment by wangs...@gmail.com on 5 Nov 2014 at 6:18