Closed GoogleCodeExporter closed 9 years ago
This is the expected behaviour considering that the protobuf encoding spec
treats repeated elements as "append", not "replace". However, this has also
come up recently, so I propose to make this optional in the v2 codebase.
Other workarounds:
- add a before-deserialization callback that wipes the field
- (v2 only) elect to skip the constructor, as this also skips field initialisers
Re fixed size; in common with other serializers it is anticipated that the
array will be reassigned during deserialization. I you want in-place handling,
consider per-index properties that are serialized separately.
Original comment by marc.gravell
on 1 Feb 2011 at 5:42
Thanks for the rapid response.
Does the spec say anything about initialization, since this is really the
issue? One could imagine:
On non-serialized construction:
Arr = new int[10];
On serialized construction the functional equivalent of:
Arr = AllProtbufElementConcatenated("Arr")
Any ideas on when v2 is production-ready?
Original comment by andersgs...@gmail.com
on 2 Feb 2011 at 7:46
The spec I'm referring to only handles the core protobuf encoding, which
doesn't refer to specific collection types, but the assumption is that arrays
are treated as "repeated" elements, which are indeed appended.
Re v2 - .... I just need to grab the time to finish it. Since this all comes
out of my non-work time it is harder to ring-fence. Soon, I hope.
Original comment by marc.gravell
on 2 Feb 2011 at 8:08
in v2, OverwriteList is an option on the ValueMember. It is not currently
exposed on the attribute usage, but count be if desired.
Original comment by marc.gravell
on 13 Jun 2011 at 12:29
Original issue reported on code.google.com by
andersgs...@gmail.com
on 1 Feb 2011 at 4:05