-
Notifications
You must be signed in to change notification settings - Fork 615
Cleanup a number of warnings in the code. #137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 9 commits
ca50431
6b94249
f72a5b3
8a98285
23e5f94
917b0f8
34e8b0e
024e9fe
4d88c95
497434f
124db7f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -44,6 +44,7 @@ | |
import com.google.firestore.v1beta1.Value; | ||
import com.google.firestore.v1beta1.Write; | ||
import com.google.protobuf.ByteString; | ||
import java.util.HashSet; | ||
import org.junit.Before; | ||
import org.junit.Test; | ||
import org.junit.runner.RunWith; | ||
|
@@ -71,7 +72,7 @@ public void testEncodesMutationBatch() { | |
new PatchMutation( | ||
key("bar/baz"), | ||
TestUtil.wrapObject(map("a", "b", "num", 1)), | ||
FieldMask.fromCollection(asList(field("a"))), | ||
FieldMask.fromSet(new HashSet<>(asList(field("a")))), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Previously this was already slightly ridiculous but this iteration is now over the top. Please add a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Deferred (slightly). If we go with a list, then I'll just revert this line. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done. |
||
com.google.firebase.firestore.model.mutation.Precondition.exists(true)); | ||
Mutation del = deleteMutation("baz/quux"); | ||
Timestamp writeTime = Timestamp.now(); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -78,6 +78,8 @@ | |
import java.util.Map; | ||
import java.util.Map.Entry; | ||
import java.util.Set; | ||
import java.util.SortedSet; | ||
import java.util.TreeSet; | ||
import javax.annotation.Nullable; | ||
|
||
/** A set of utilities for tests */ | ||
|
@@ -430,13 +432,15 @@ public static PatchMutation patchMutation( | |
|
||
boolean merge = updateMask != null; | ||
|
||
// We sort the fieldMaskPaths to make the order deterministic in tests. | ||
Collections.sort(objectMask); | ||
// We sort the fieldMaskPaths to make the order deterministic in tests. (Otherwise, when we | ||
// flatten a Set to a proto repeated field, we'll end up comparing in iterator order and | ||
// possibly consider {foo,bar} != {bar,foo}.) | ||
SortedSet<FieldPath> fieldMaskPaths = new TreeSet<>(merge ? updateMask : objectMask); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hrm. I wonder if this is really necessary. Were we just sorting them before so equals() would work out? If so, then we're already good. What happens if you use a HashSet here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The production code passes a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh. I thought it was a HashSet. In any case, I'm fine with using a TreeSet, but the comment about sorting seems confusing / wrong now. Perhaps just remove it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The sort is because we compare the actual protos (post serialization from models to protos) in the serializer tests. Sets/Lists are flattened down to repeated fields in iterator order. That maps well for lists (since order is preserved) but isn't great for sets, since our test would incorrectly state that {foo,bar} != {bar,foo}. (We couldn't have used Model.equals() here, because of the whole Collection.equals() not making sense when both lists and sets are involved, though if the test happened to use the same type as the model that it had set up, then we would've gotten away with it.) The old code didn't know if a list or set was used (since a Collection could be either), so it sorted them to ensure everything was fine. The new code (currently) knows that sets are used. Therefore, it needs to sort them to ensure the tests consider the results correct. If we switch to list, I think we could drop the sort altogether. I've updated the comment to hopefully make this clearer. (Though will remove it if we do the set->list thing.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah! Comment makes perfect sense now, thanks. |
||
|
||
return new PatchMutation( | ||
key(path), | ||
objectValue, | ||
FieldMask.fromCollection(merge ? updateMask : objectMask), | ||
FieldMask.fromSet(fieldMaskPaths), | ||
merge ? Precondition.NONE : Precondition.exists(true)); | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optional: what's the reason to prefer
Set
to aList
? AFAICS,mask
is never used for lookup; the only access is iterating over all the elements (line 63), for whichList
will likely be faster.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly, it doesn't matter much. But here's the reasons I went with set:
a) The masks are conceptually unordered.
i) which is particularly relevant in the .equals() method, since presumably FieldPath.fromX({"foo", "bar"}) and FieldPath.fromX({"bar", "foo"}) should be considered equivalent.
b) Should avoid accidental duplicates. (Though I don't think duplicates would actually hurt us.)
I don't think speed is a concern in this case: it's hard to imagine having much more single digits of these; plus we're probably about to hit either the network or the disk which should dominate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that Set is the natural data structure (and perf, etc. aren't major concerns). That said, we may now get slightly different behavior than on other platforms (e.g. with regard to duplicates), though I don't think that's a big deal, and the Android behavior will probably be more correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I agree with the academic distinction we're drawing here, this is a change in behavior that we really should mirror out to the other platforms. Once you consider that, is this change really worth it considering that the code works as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, Collection isn't right, but I'd be ok with List if we don't think ordering/duplicates are overly relevant. If we do think they're relevant, I'm happy to port to the other platforms.
Another option is to leave it as Collection, but eliminate the .equals() method and use the default referential equality instead. Looking at this a bit closer, I don't think we ever actually call FieldMask.equals()... at least not in the test suite. (Tested by changing the implementation to unconditionally throw and re-run all tests.) We do allow callers to fetch the mask, but we only ever iterate over the contents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with any of these options (including keeping it as a Set as you have it now).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok; I've gone with set. I'll port to the others.