Closed henridf closed 4 years ago
This raises good questions. If we index and get an error, the file should not be left behind. But if we index a chunk, and there were no instances of the key, then I think we want a microindex file with an "empty" index trailer so the microindex pruner can skip a search for said key. In this case, I think an empty trailer wants to include an empty sections[] array and a TypeNull for the key type since we don't know the type of an unencountered key.
Verified in zar
commit b7023d5
.
Repeating the steps, at this point we can see there's no longer an empty file left behind:
$ tree -s $ZAR_ROOT
/Users/phil/logs
├── [ 128] 20091119
│ ├── [ 116] 1258594909.85978.zng
│ └── [ 64] 1258594909.85978.zng.zar
└── [ 248] zar.json
2 directories, 2 files
That means if the user marched ahead and tried to query against the index anyway, they'd now get a different error message:
$ zar find orig_h=192.168.2.1
item does not exist
This error message is problematic in its own way, but this has already been identified and is tracked in #1137.
Thanks @mccanne!
This was described in https://github.com/brimsec/zq/issues/815#issuecomment-651423326. Splitting out into its own bug: