After your comment I revisited the issue. It's actually right what the docs state, so the `allowImplicit` flag belongs underneath the `collections` attribute. I first thought it should go on the main level, because when I tried it made no difference. But it turned out I had some typo in my reproduce code.
The actual reason for the issue that you were facing was different: when specifying the list of collections for the transaction, there are the attributes `read` and `write`. In your case, you specified the `foxxdebug` collection as both `read` and `write`. This is kind of redundant, as `write` includes `read` already, so using `write: "foxxdebug"` would have been sufficient already. Adding the same collection as both read and write seems to have an unwanted side effect, with the outcome that `read` wins. That means when using the collection in write mode in the transaction (for the insert operation) the transaction will complain. Adding the collection as write-only will work however. Adding it as read-only will of course complain intentionally when the collection is used in write mode. So the fix clearly is that the collection should be added in write-only mode to the transaction, and that the _executeTransaction function() should automatically treat it like this when a collection is specified in both `read` and `write`. I just changed that behavior in the 2.8, 3.0 and devel branches, so that fix will be incorporated in future releases. Sorry for the confusion, it wasn't fully obvious to me in the beginning, and I was convinced that `allowImplicit` belongs on the top-level, but you were right. Best regards Jan Am Mittwoch, 29. Juni 2016 10:15:47 UTC+2 schrieb Thomas Weiss: > > Thanks for looking into this, so this means that there are errors in your > docs: > https://docs.arangodb.com/2.8/Transactions/TransactionInvocation.html > https://docs.arangodb.com/2.8/Transactions/LockingAndIsolation.html > > Cheers, > thomas > > On Wednesday, June 29, 2016 at 4:13:02 PM UTC+8, Jan wrote: >> >> Regarding the actual "allowImplicit" flag. >> This works fine for me, however, the flag needs to be specified on the >> topmost level of the transaction object, i.e. >> >> db._executeTransaction({ >> collections: { >> read: ['foxxdebug'], >> write: ['foxxdebug'] >> }, >> allowImplicit: false, >> action: function () { >> ... >> }); >> >> I think in your code example the flag is set in some nested level, inside >> the "collections" attribute, from where it will not be picked up. >> >> Best regards >> Jan >> >> >> >> Am Mittwoch, 29. Juni 2016 04:51:51 UTC+2 schrieb Thomas Weiss: >>> >>> Hi Jan, >>> >>> It seems that this is the exact same answer to an other issue I >>> reported, but I don't think the issues are related. >>> >>> Thanks, >>> Thomas >>> >>> On Tuesday, June 28, 2016 at 8:57:13 PM UTC+8, Jan wrote: >>>> >>>> Hi Thomas, >>>> >>>> I used your code to reproduce the issue and it's partly related. >>>> The problem in this case is not that there are immutable objects, but >>>> that the call to `byExample(...).count()` returns an unexpected value. >>>> >>>> var fromCount1 = db.foxxdebug.byExample({ _from: from, request: false >>>> }).count(); >>>> >>>> The `byExample()` returns an object of type `SimpleQueryByExample`, and >>>> when calling `toArray()` on this, the results are correct, before and >>>> after >>>> the update. >>>> However, when calling `count()` on that object, this will also >>>> correctly execute the simple query, but sometimes returns a wrong result >>>> for `count`. The reason for this is that internally the result is produced >>>> by an index lookup and then may need to be post-filtered in order to >>>> return >>>> only those documents that match all conditions. In this case, the >>>> byExample >>>> will use the edge index on `_from` and then post-filter the result using >>>> the `request == false` condition. The result of post-filtering is also >>>> correct, however, the `count` value of the query is not adjusted. `count` >>>> in this case will return the number of documents before post-filtering. >>>> >>>> In your case the number of documents with the queried `_from` and `_to` >>>> values don't change due to the replace, so the `count` values before and >>>> after the replace are identical. Clearly it's a bug that the count value >>>> is >>>> wrong, and I just fixed it in the 2.8 branch. I checked that it's already >>>> working fine in 3.0, and 2.8 is the last affected version. >>>> >>>> By the way, the workaround to prevent the issue from occurring is to >>>> not use `byExample(...).count()` but instead use >>>> `byExample(...).toArray().length`. >>>> We plan to build a new 2.8 release this week end. >>>> >>>> Best regards >>>> Jan >>>> >>>> Am Freitag, 24. Juni 2016 15:11:53 UTC+2 schrieb Thomas Weiss: >>>>> >>>>> Hi there, >>>>> >>>>> I was debugging a different topic in my Foxx app and decided to give >>>>> the 'allowImplicit' flag a try (to make sure that all the collections I >>>>> read in my transactions were declared). But I found that, even if all >>>>> collections are declared, adding this flag would raise an error. Here is >>>>> a >>>>> simple example to reproduce that (tested on 2.8.7): >>>>> >>>>> controller.post('/foxxdebug', function (req, res) { >>>>> var from = 'foxxdebug/123'; >>>>> var to = 'foxxdebug/456'; >>>>> db._executeTransaction({ >>>>> collections: { >>>>> read: ['foxxdebug'], >>>>> write: ['foxxdebug'], >>>>> allowImplicit: false >>>>> }, >>>>> action: function () { >>>>> db.foxxdebug.insert(from, to, {}); >>>>> var fromCount = db.foxxdebug.byExample({ _from: from }). >>>>> count(); >>>>> var toCount = db.foxxdebug.byExample({ _to: to }).count(); >>>>> res.json({ fromCount: fromCount, toCount: toCount }); >>>>> } >>>>> }); >>>>> }); >>>>> >>>>> Note that the 'foxxdebug' was created, but this call would always fail >>>>> with the 'unregistered collection used in transaction' error! >>>>> >>>>> Thomas >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "ArangoDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
