I am not talking about user-facing insert operator, which Abdullah implemented, but rather LSMBtree-level upset, which seems to be a separate index-modification operation according to org.apache.hyracks.storage.am.common.ophelpers.IndexOperation According to https://github.com/apache/incubator-asterixdb-hyracks/blob/master/hyracks/hyracks-storage-am-btree/src/main/java/org/apache/hyracks/storage/am/btree/impls/BTree.java#L329-L331 <https://github.com/apache/incubator-asterixdb-hyracks/blob/master/hyracks/hyracks-storage-am-btree/src/main/java/org/apache/hyracks/storage/am/btree/impls/BTree.java#L329-L331> it seems that it is safe to make changes to the fields as long as they are not keys, which is indeed the case with metadata changes I was talking about.
> On Feb 14, 2016, at 14:49, Mike Carey <[email protected]> wrote: > > An upsert would be fine, I would think; perhaps we didn't have it back when > that was done. > (Note that depending on which layer you are talking about, upsert is > synonymous with a > delete and then a (re)insert - though you are probably many layers below my > world at the > user level where that's the case. :-)) > > On 2/14/16 2:47 PM, Ildar Absalyamov wrote: >> A number of metadata-related changes, like creating a new index involves >> several stages: >> 1) Create an index with PENDING_ADD_OP >> 2) Bulkload the index >> 3) Delete the index with PENDING_ADD_OP and reinsert it with PENDING_NO_OP >> >> The last operation causes the issue with stats collection for particular >> index: sometimes the stats are already persisted before 3) starts executing, >> so they are become a subject to cascade delete, hence are lost. >> I was wondering why an upset is not an option for step 3 instead of >> insert-delete? Are there any complications from transaction logging >> perspective? >> >> Best regards, >> Ildar >> >> >> >> >> > Best regards, Ildar
