| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Add a travis stage that tests building Firestore with Xcode 8.3.
* Simulate on a device available in Xcode 8
* Fix compile errors under Xcode 8.3.3
* Remove Firestore_SwiftTests_iOS from the Firestore_Tests_iOS Scheme
I'll create a new target for this but in another PR.
* Add an entry to CHANGELOG.md
|
| |
|
| |
Were showing up in xcode build (but not cmake build)
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also "fixed" BadFieldValueTagWithOtherValidTagsPresent test by changing
'false' to 'true'. Details: Depending on the version of nanopb, nanopb
would explicitly encode 'false', which shouldn't be done in proto3. When
it's explicitly encoded, the test worked properly. But when it was
(properly) dropped, the invalid tag is the only field that's actually
encoded, thus violating the assumptions of the test, leading to a test
failure. s/false/true fixes it, as now the boolean_value field is
(properly) encoded regardless of version.
|
| | |
| |
| |
| | |
(#1377)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Normally, this would be unexpected, as only a single entry in the Value
proto *should* be present. However, the proto docs state that parsers
should be able to handle repeated fields. (In the case of repeated
fields, the last one "wins".)
|
| | |
| |
| |
| | |
... where neither 'found' nor 'missing' fields set.
|
| |/ |
|
| |
|
|
|
|
| |
Note that it isn't possible to *serialize* NoDocuments.
Still TODO:
- Error handling
|
| |
|
| |
Roughly s/google::firebase::v1beta1/v1beta1/g
|
| |
|
|
|
|
|
| |
* [De]serialize non-empty Document instances
Still TODO:
- NoDocument
- ErrorHandling
|
| |
|
|
|
|
|
|
|
| |
* [De]serialize empty Document instances
Still TODO:
- non-empty
- NoDocument
- ErrorHandling
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is more interesting than the serializing case, as we should expect
to see occasional corruption of our input byte vector.
|
| |
|
|
|
|
| |
Previously, the tests would compare serialization results against a
precomputed (via protoc) array of bytes. Now they serialize via our
nanopb based class and deserialize via libprotobuf (and vice versa) and
then ensure the result is the same as the input
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add a .clang-tidy configuration for Firestore C++
* Fix clang-tidy warnings
* typedef -> using
* const ref + rvalue ref -> pass by value
* NULL -> nullptr
* remove useless default initializations
* remove useless const value-type parameter declarations (definitions
can still use them)
* use auto instead of repeating types in a cast
* Fix typos
* Address use of static method through instance warnings
* Address use after move warnings
|
| |
|
|
|
|
|
|
| |
Deserializing not handled yet.
Note that the serializing case is fairly uninteresting, as assuming
valid input is passed in, there's no real reason why it should fail (and
if it does fail, it indicates a gross violation of our understanding of
the system.)
|
| | |
|
| |
|
|
|
|
|
| |
* Rename Writer::Encode* methods to Writer::Write*
* Rename: s/stream/writer/ (approximately)
but only where it applies to Writer (rather than pb_ostream_t).
|
| |
|
| |
These can (recursively) contain other FieldValues.
|
| | |
|
| |
|
|
|
|
|
|
| |
This will likely only apply for proto messages that use 'oneof's. (Because we need to serialize these manually.)
The problem was that as we were adding additional types, TypeValue was evolving into a parallel implementation of the FieldValue union.
When serializing/deserializing oneofs we need to supply a custom value to serialize and a custom function to do the work. There's no value in translating from FieldValue to TypeValue just to store as this custom object. We might as well just store the FieldValue model directly and write the custom serializer/deserializer to use the model directly.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Build (grpc's) nanopb with -DPB_FIELD_16BIT
We require (at least) 16 bit fields. (By default, nanopb uses 8 bit
fields, ie allowing up to 256 field tags.)
Also note that this patch adds this to grpc's nanopb, rather than to our
nanopb. We'll need to eventually either:
a) we instruct grpc to use our nanopb
b) we rely on grpc's nanopb instead of using our own.
(^ marked as a TODO for now.)
* Add some dependant protos
Imported from protobuf. Nanopb requires these to be present (though
anything using libprotobuf does not, as these are already built into
that.)
* Add generated nanopb protos based off of newly added proto definitions
* Build the nanopb protos
* Serialize and deserialize null
|
| | |
|
|
|
Use remote/serializer placeholder class as a hook for the test to ensure
nanopb headers can be found, and test can be linked.
|
Gil
rsgowman