Allows non ancestor queries inside a transaction in remote api context #383
Conversation
|
Interesting, this code was added in 2012 without much context other than Also fix ID allocation in a transaction to not write entities." I'll try to chat with the author. Maybe a better change would be to introduce a system property that would control this behavior and you would turn it on for your app. |
| if (!query.hasAncestor()) { | ||
| throw new ApiProxy.ApplicationException( | ||
| BAD_REQUEST.getNumber(), "No ancestor in transactional query."); | ||
| } | ||
| // Make __entity_group__ key | ||
| OnestoreEntity.Reference.Builder egKey = | ||
| result.getEntityGroupKeyBuilder().mergeFrom(query.getAncestor()); |
There was a problem hiding this comment.
Here, we use getAncestor(), so we must have the optional field, so we must have query.hasAncestor() being true.
Can you explain how it works for you?
There was a problem hiding this comment.
You are right, I'm sorry, but I thought that the fix was trivial, but this is not the case.
Moreover, that code enforces the optimistic with entity group lock of the old datastore.
I'll try to understand if and how to fix it; in the meantime, you can trash this PR.
|
no pb. |
In the pull request #366 I've left behind a change inside the remote api servlets and so, in remote api context, the non ancestor queries insieme a transaction fails.
In this pull request I've removed the check inside the two remote api servlets.