foo.bar1 = 1
foo.bar2 = 2
foo.bar3 = 3
foo["bar1"] = 1
foo["bar2"] = 2
foo["bar3"] = 3
Doing this 20 times is kinda clumsy. And __dict__ doesnt work.
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop re
Why does adding JSON require dropping unknown fields? So long as fields are
keyed to field number, I don't see why the JSON encoding requires special
treatment with respect to the binary one.
I can understand how transitioning between major versions may require
breaks in compatibility. However, pr
After studying proto3 pretty carefully, I’ve come around quite a bit on these
changes:
I believe adding JSON requires dropping unknown fields. You simply cannot
preserve unknown fields and properly support multiple encodings.
I’m less sure about replacing extension support with Any. Extension
Big fan of 4, 5, 6, and 7. Huge un-fan of 2, and 3. I am mixed on 1 because
I love the removal of required fields, hate the removal of field presence.
All the changes I dislike are significant losses in functionality and break
compatibility with existing users of proto2 and I'd be interested to
und
On Wednesday, May 18, 2016 at 11:32:03 AM UTC-7, Feng Xiao wrote:
>
>
>
> On Tue, May 17, 2016 at 7:53 PM, Teddy Zhang > wrote:
>
>> I'm really not happy to see that proto3 removed the ability in generate
>> code for check whether a field exits or not.
>>
>> For a message like this:
>> message
On Wednesday, May 18, 2016 at 11:32:03 AM UTC-7, Feng Xiao wrote:
>
>
>
> On Tue, May 17, 2016 at 7:53 PM, Teddy Zhang > wrote:
>
>> I'm really not happy to see that proto3 removed the ability in generate
>> code for check whether a field exits or not.
>>
>> For a message like this:
>> message
On Tue, May 17, 2016 at 7:53 PM, Teddy Zhang wrote:
> I'm really not happy to see that proto3 removed the ability in generate
> code for check whether a field exits or not.
>
> For a message like this:
> message Test1 {
> required int32 a = 1;
> }
> If field a is present, the encoded message wi
On Wed, May 18, 2016 at 9:27 AM, Artem Kazakov wrote:
> +1
> Yes, a checklist would be extremely helpful.
>
>
> On Friday, April 29, 2016 at 5:04:56 PM UTC-4, Kostiantyn Shchepanovskyi
> wrote:
>>
>> It would be nice to have a migration guide (checklist) somewhere, like:
>>
>> 1. All fields shoul
Protobuf schema evolution rules:
https://developers.google.com/protocol-buffers/docs/proto#updating
On Wednesday, May 18, 2016 at 11:09:15 AM UTC-7, Artem Kazakov wrote:
>
> +1
> Yes, a checklist would be extremely helpful.
>
> On Friday, April 29, 2016 at 5:04:56 PM UTC-4, Kostiantyn Shchepanov
+1
Yes, a checklist would be extremely helpful.
On Friday, April 29, 2016 at 5:04:56 PM UTC-4, Kostiantyn Shchepanovskyi
wrote:
>
> It would be nice to have a migration guide (checklist) somewhere, like:
>
> 1. All fields should be optional.
> 2. Do not use custom defailt values.
> 3. All enums
Hi all,
If you ever had runtime compatibility issues with different versions of
protobuf-java used in the same application,
protobuf-java-shaded-[241|250|261] may be of interest:
https://github.com/os72/protobuf-java-shaded-241
https://github.com/os72/protobuf-java-shaded-250
https://github.com
I had a similar discussion some months ago. What you want is to generate
the TypeRegistry at Runtime. I did this by using the following approach:
https://groups.google.com/d/msg/protobuf/fnhsS9tVhyc/9pkapOl-AQAJ
Therefore you don't have to gereate the file descriptors but just use the
ones you
And instead of encapsulating the field mask into a new message, you should
be alright to just use google.protobuf.FieldMask as it is already a message
by itself (in case that you don't add other data to RepAndOptMask of
course).
Am Dienstag, 17. Mai 2016 10:51:04 UTC+2 schrieb Denis Bakhvalov:
Hi Feng,
Thank you for the answer. Good point about redundant type information in
the header message.
Regards,
/David
On Monday, May 16, 2016 at 11:01:47 PM UTC+2, Feng Xiao wrote:
>
>
>
> On Mon, May 16, 2016 at 11:30 AM, 'David Koch' via Protocol Buffers <
> prot...@googlegroups.com > wrote:
This works in Java, perhaps you can adapt it to C# (?)
https://github.com/os72/protobuf-dynamic
Is there DynamicMessage in the C# API?
On Monday, May 16, 2016 at 10:30:18 AM UTC-7, jigmesh...@gmail.com wrote:
>
> Hi,
>
> I wanted to generate FileDescriptor dynamically from .proto without
> refer
At least in Java, you can do everything fully dynamically at runtime. The
native API can get quite confusing (between all the
protos/descriptors/files...). I distilled following wrapper to make it
easier:
https://github.com/os72/protobuf-dynamic
On Friday, April 1, 2016 at 4:32:29 PM UTC-7, Jo
Check out the protobuf schema evolution rules, you may find it's actually
simpler with protobuf and don't have to keep track of writer schemas like
in Avro:
https://developers.google.com/protocol-buffers/docs/proto#updating
Corresponding to Avro GenericRecord you would use protobuf DynamicMessag
17 matches
Mail list logo