[protobuf] how to ignore some fields when serialize object in proto3

[哈]

just like 
protected void init(Kryo kryo) {
kryo.setDefaultSerializer(CompatibleFieldSerializer.class);
Serializer serializer = kryo.getSerializer(More.class);
if (serializer instanceof FieldSerializer) {
FieldSerializer fieldSerializer = (FieldSerializer)serializer;
fieldSerializer.removeField("test");
}
}

when i serialize object， kryo will ignore 'test' filed.
can i do this in proto3 ?

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/0ded41d3-6cbc-4cf3-85fb-b5f16b852e03n%40googlegroups.com.

Re: [protobuf] Clarifying for Sharing Messages Between Python and C++

[NoAnyLove (NoAnyLove)]

I see, thanks!

在2022年11月3日星期四 UTC-5 10:22:46 写道：

> Yes, you are right. Serializing a message and parsing it back on the other 
> side will always work, but starting from 4.21.0, Python apps won't be able 
> to share messages directly without that step.
>
> On Wed, Nov 2, 2022 at 10:32 PM No AnyLove (NoAnyLove)  
> wrote:
>
>> Protobuf Python has switched to upb as default backend since 21.0, 
>> according to the release notes 
>> , which 
>> significantly improves the performance. But according to notes here 
>> and
>>  
>> here 
>> ,
>>  
>> it implies the upb backend causes break when it shares messages between 
>> Python and C++.
>>
>> I'm a little bit confused here, as it can refer to 2 different situations,
>>
>> A Python app uses C++ extension, which passes the protobuf message 
>> objects between each other via function/class calls
>> A Python app and a C++ app transmit protobuf messages via 
>> socket/pipe/etc., i.e., it needs to serialize/deserialize the messages
>>
>> According to the following note 
>> and
>>  
>> protobuf advertising it as language-neutral, I assume the break only 
>> happens in the 1st situation, but want to double check that I'm not making 
>> mistake here.
>>
>> > Prior to Python 4.21.0, Python apps could share messages with C++ using 
>> a native extension.
>>
>> Thanks. 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to protobuf+u...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/protobuf/7c32529f-ac86-4207-a9a1-2865cbf4661an%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/261b40a5-665a-4aa9-a56d-f3e091ebaaf9n%40googlegroups.com.

[protobuf] Errors running v3.21.5 autogen.sh on Cygwin/Win10

[Davorin Mista]

I made sure to checkout with Unix-style line endings since I'm trying to 
build it all in the cygwin terminal but I still keep running into errors. 
Do I need to have a particular version of libtool? It keeps telling me to 
run autoupdate, which I subsequently did on the command line, but it's 
still saying it so I'm not sure what to make of that.

Any help is appreciated. 
Davorin

Here the full log when running autogen.sh:

$ ./autogen.sh
+ test -d third_party/googletest
+ mkdir -p third_party/googletest/m4
+ autoreconf -f -i -Wall,no-obsolete
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:30: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:30: You should run autoupdate.
m4/libtool.m4:100: AC_PROG_LIBTOOL is expanded from...
configure.ac:30: the top level
configure.ac:51: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:51: You should run autoupdate.
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/autoconf/c.m4:72:
 
AC_LANG_C is expanded from...
m4/acx_pthread.m4:63: ACX_PTHREAD is expanded from...
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/m4sugar/m4sh.m4:699:
 
AS_IF is expanded from...
configure.ac:51: the top level
configure.ac:51: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:51: You should run autoupdate.
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/autoconf/general.m4:2920:
 
AC_TRY_LINK is expanded from...
m4/acx_pthread.m4:63: ACX_PTHREAD is expanded from...
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/m4sugar/m4sh.m4:699:
 
AS_IF is expanded from...
configure.ac:51: the top level
Can't exec "automake": No such file or directory at 
/usr/share/autoconf2.7/Autom4te/FileUtils.pm line 274.
autoreconf-2.71: error: automake failed with exit status: 1

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/cee1c92c-0129-4f99-a02b-77ef2b8bcb3bn%40googlegroups.com.

Re: [protobuf] Protobuf 3 optional vs FieldMasks

['Adam Cozzette' via Protocol Buffers]

>From a protobuf perspective, either approach should work, so I think it is
mostly a matter of preference. I think you are right that FieldMasks
predate proto3 optional fields and were originally designed to accommodate
the lack of optional fields in proto3. Now that proto3 has optional fields,
they are a valid alternative to FieldMask.

On Wed, Nov 2, 2022 at 11:26 AM Jeff Sawatzky 
wrote:

> Now that protocol buffers 3 has support for optional fields
>  which lets you test
> whether the field was set or not, are FieldMasks still useful?
>
> For instance, when implementing an Update method in gRPC which allows the
> client to update only the fields that they pass, should the method take a
> message with `optional` fields or a FieldMask? Is it a matter of personal
> preference? Or is there a benefit to one of them?
>
> We also want to expose the gRPC API as a JSON/HTTP API using either
> grpc-gateway or envoy with the grpc_json_transcoder filter. Do these have a
> preference with either pattern?
>
> I see that Googles AIPs  recommend FieldMasks
> for Update methods, but this could have been done before `optional` was
> available?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/protobuf/9f8b2b48-66fe-4f97-b822-84402309a5edn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/CADqAXr4MNGCWnx__GO27Zf-1MeAB1hkAV5nyqWnZ4ugHHCEGFg%40mail.gmail.com.

Re: [protobuf] protogen golang - finding source line for diagnostics?

['Adam Cozzette' via Protocol Buffers]

Things like comments and line numbers from the .proto file are represented
in the SourceCodeInfo message here
.
Unfortunately I'm not familiar enough with Go protos or protogen to say
exactly how to get ahold of that, but this Location

type looks promising.

On Thu, Nov 3, 2022 at 3:07 AM Steve Simon  wrote:

> Hi,
>
> I am using protogen for go successfully. We are using
> extend google.protobuf.ServiceOptions {  as we need to
> encode extra fields for our backend.
>
> When I find typos in the serviceOptions I am parsing I would like to
> generate diagnostics which reference the source proto file and line number.
>
> I have not found any way to extract the source line number for an object
> (Service record in my case). Is it possible?
>
> -Steve
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/protobuf/e5e894ff-fba1-4889-9445-12a629d19907n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/CADqAXr6FHekuf5%3D4CH5a97ZsoLTczrmJMjzvQRr%2BHk-wAhB2BQ%40mail.gmail.com.

Re: [protobuf] Clarifying for Sharing Messages Between Python and C++

['Adam Cozzette' via Protocol Buffers]

Yes, you are right. Serializing a message and parsing it back on the other
side will always work, but starting from 4.21.0, Python apps won't be able
to share messages directly without that step.

On Wed, Nov 2, 2022 at 10:32 PM No AnyLove (NoAnyLove) 
wrote:

> Protobuf Python has switched to upb as default backend since 21.0,
> according to the release notes
> , which
> significantly improves the performance. But according to notes here
> and
> here
> ,
> it implies the upb backend causes break when it shares messages between
> Python and C++.
>
> I'm a little bit confused here, as it can refer to 2 different situations,
>
> A Python app uses C++ extension, which passes the protobuf message
> objects between each other via function/class calls
> A Python app and a C++ app transmit protobuf messages via
> socket/pipe/etc., i.e., it needs to serialize/deserialize the messages
>
> According to the following note
> and
> protobuf advertising it as language-neutral, I assume the break only
> happens in the 1st situation, but want to double check that I'm not making
> mistake here.
>
> > Prior to Python 4.21.0, Python apps could share messages with C++ using
> a native extension.
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/protobuf/7c32529f-ac86-4207-a9a1-2865cbf4661an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/CADqAXr57KqvUL_WH9fotz3FrKQkF32Ue-7sGAVPsTu4xFgx6OQ%40mail.gmail.com.

[protobuf] protogen golang - finding source line for diagnostics?

[Steve Simon]

Hi,

I am using protogen for go successfully. We are using 
extend google.protobuf.ServiceOptions {  as we need to
encode extra fields for our backend.

When I find typos in the serviceOptions I am parsing I would like to 
generate diagnostics which reference the source proto file and line number.

I have not found any way to extract the source line number for an object 
(Service record in my case). Is it possible?

-Steve

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/e5e894ff-fba1-4889-9445-12a629d19907n%40googlegroups.com.