Cannot transition from not multi key to multi key in multi statement transaction

[superisaac]

Here is how to create this issue:

mongo testbed
TokuMX mongo shell v2.0.0-mongodb-2.4.10
connecting to: testbed
> db.tx.ensureIndex({'vout.addrs': 1})
> var doc = {'vout': [{'addrs': ['hello']}, {'addrs': ['world']}]};
> db.runCommand('beginTransaction')
{ "status" : "transaction began", "ok" : 1 }
> db.tx.insert(doc)
Cannot transition from not multi key to multi key in multi statement transaction

[esmet]

That is correct

[superisaac]

could you tell me the reason why it is correct? or can you show me a workaround to insert this kind of documents within a multi statement transaction?

[esmet]

Atomic rollback and snapshoting of the multi key indicator was hard to reason about at the time, so we disallowed that transition in an explicit transaction.

You can work around this not ensuring a collection is multi key before writing to it in an explicit txn.

Sent from my iPhone

On Apr 24, 2015, at 7:50 PM, Zeng Ke notifications@github.com wrote:

can you tell the reason why it is correct?

— Reply to this email directly or view it on GitHub.

[erikekblom]

I have also experienced this problem and the workaround was to drop all indexes. Later I created the multi key indexes again and have not since had this problem in the database in question.

Now I have created a new database and have the same problem on that and can make the same workaround.

Is there any way to determine whether a collection with multi key indexes is exposed to this restriction? I.e. determine if the "transition from not multi key to multi key" has already occurred?

Best regards Erik Ekblom

[leifwalsh]

A query that uses a multikey index, when explain()ed, will show that fact. 

Cheers, Leif

On Wed, Aug 12, 2015 at 4:01 AM, erikekblom notifications@github.com wrote:

I have also experienced this problem and the workaround was to drop all indexes. Later I created the multi key indexes again and have not since had this problem in the database in question. Now I have created a new database and have the same problem on that and can make the same workaround. Is there any way to determine whether a collection with multi key indexes is exposed to this restriction? I.e. determine if the "transition from not multi key to multi key" has already occurred? Best regards

Erik Ekblom

Reply to this email directly or view it on GitHub: https://github.com/Tokutek/mongo/issues/1224#issuecomment-130210259

[bitliner]

to me it is happening even without running a multi-statement transaction (i do not run any beginTransaction). is this behavior as expected?

What the code does is to create some indexes, and insert some document.

Also in my case, if I drop the database, then it works fine