subject:"\[protobuf\] Re\: Dynamic Message"

Re: [protobuf] Re: Dynamic message schema verification

2022-10-31 Thread 'Adam Cozzette' via Protocol Buffers

What you're trying to do should work in the sense that it will determine
whether the message is parsable as the type given in the descriptor.
However, you are correct that a message of one type can very often be
parsed successfully as a completely different type. This is indeed by
design, since this level of flexibility is needed so that message
definitions can evolve over time without breaking wire compatibility.

On Fri, Oct 28, 2022 at 10:37 PM Idan Asulin  wrote:

> Didn't mention but I'm using the Go official library
>
> On Saturday, 29 October 2022 at 08:35:16 UTC+3 Idan Asulin wrote:
>
>> I'm trying to implement data contract logic.
>> I've 2 services switching messages with each other.
>> Service A send messages in some format + the file descriptor proto of the
>> .proto file used to generate it. Service B gets them both, the message and
>> the file descriptor proto and has to ensure the message doesn't break the
>> schema defenition.
>>  What I've did until now is to create a dynamic message instance using
>> the descriptor proto and tried to unmarshal the message into the dynamic
>> message instance, and in case no error occurred during the unmarshal
>> process it counts as a success (message doesn't break the schema).
>>
>> 1. Is it ok to rely on the unmarshal function in order to decide whether
>> the message is ok?
>> 2. I noticed that even in case I'm sending messages with totally
>> different schemas the unmarshal succeed. the only way I found to cause the
>> unmarshal to fail is by sending proto2 messages with missing required
>> fields.
>> So is it by design that every message can be unmarshled using a totally
>> different schema definition?
>>
> --
> 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/59f6cb9f-33ae-4fc1-ba07-93d3d8c90431n%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/CADqAXr58PCmZuzjYV4BaGKeacUPFEK-J%3D5ky1f7TrofBK8%2Bhhw%40mail.gmail.com.

[protobuf] Re: Dynamic message schema verification

2022-10-28 Thread Idan Asulin

Didn't mention but I'm using the Go official library

On Saturday, 29 October 2022 at 08:35:16 UTC+3 Idan Asulin wrote:

> I'm trying to implement data contract logic.
> I've 2 services switching messages with each other.
> Service A send messages in some format + the file descriptor proto of the 
> .proto file used to generate it. Service B gets them both, the message and 
> the file descriptor proto and has to ensure the message doesn't break the 
> schema defenition.
>  What I've did until now is to create a dynamic message instance using the 
> descriptor proto and tried to unmarshal the message into the dynamic 
> message instance, and in case no error occurred during the unmarshal 
> process it counts as a success (message doesn't break the schema).
>
> 1. Is it ok to rely on the unmarshal function in order to decide whether 
> the message is ok?
> 2. I noticed that even in case I'm sending messages with totally different 
> schemas the unmarshal succeed. the only way I found to cause the unmarshal 
> to fail is by sending proto2 messages with missing required fields.
> So is it by design that every message can be unmarshled using a totally 
> different schema definition? 
>

-- 
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/59f6cb9f-33ae-4fc1-ba07-93d3d8c90431n%40googlegroups.com.

Re: [protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

2013-01-20 Thread Feng Xiao

On Sat, Jan 19, 2013 at 2:13 AM, m  wrote:

> The furthest I followed it was looking down into the implementation of
> CopyFrom() which calls MergeFrom().  Inside of MergeFrom() there's a spot
> where it calls something like "dynamic_cast_if_available" which returns
> NULL (failing to dynamic_cast).

Returning NULL shouldn't cause a segment fault. The generated code should
be able to handle this NULL case properly.


>
>
> On Thursday, January 17, 2013 10:20:13 PM UTC-8, Feng Xiao wrote:
>>
>> Glad that you found what works for you. What baffles me is why CopyFrom()
>> segfaults when given a DynamicMessage.  DynamicMessage can't be cast to
>> Foo, but foo.CopyFrom() gets to be working with it. Did you find why it
>> segfaults?
>>
>> On Friday, January 18, 2013 3:31:48 AM UTC+8, m wrote:
>>>
>>> Thanks for your reply.
>>>
>>> My application links against all the stub proto sources of the types I
>>> will be creating.  What I've found works is if I use the default(?)
>>> descriptor pool (google::protobuf::**DescriptorPool::generated_**pool())
>>> and the default message factory (google::protobuf::**
>>> MessageFactory::generated_**factory()).  Given the type name and the
>>> content, I have a simple function that more or less does this:
>>>
>>> const gpb::Descriptor* descriptor = gpb::DescriptorPool::**
>>> generated_pool()->**FindMessageTypeByName( "my.package.Foo" );
>>>
>>>
>>>
>>> gpb::MessageFactory* factory = gpb::MessageFactory::**
>>> generated_factory();
>>>
>>>
>>>
>>>
>>> const gpb::Message* prototype = factory->GetPrototype( descriptor );
>>>
>>>
>>>
>>>
>>> gpb::Message* message = prototype->New();
>>>
>>>
>>>
>>> gpb::Message* m = gpb::TextFormat::**ParseFromString( "blah: \"some
>>> string\" bleh: 3", message );
>>>
>>>
>>>
>>>
>>>
>>> On Wednesday, January 16, 2013 4:15:53 PM UTC-8, m wrote:

 Hi All,

 I'm seeing an incompatibility between a dynamically generated
 google::protobuf::Message (DynamicMessage?) created with a
 google::protobuf::**DynamicMessageFactory and a normal
 google::protobuf::Message.

 What I'm running up against ultimately comes down to this: I can't
 dynamic_cast a DynamicMessage to a known derived type of
 google::protobuf::Message.  For example, let's say my proto file has the
 following message:

 package my.package;

 messsage Foo
 {
   string blah = 1;
   uint32 bleh = 2;
 }


 and I successfully create a my::package::Foo with some code along the
 lines of:

 const google::protobuf::Descriptor* descriptor = 
 myImporter.pool()->**FindMessageTypeByName(
 "my.package.Foo" );

 google::protobuf::Message* message = 
 myDynamicMessageFactory.**GetPrototype(
 descriptor )->New();


 after populating message successfully with other commands not shown
 here, I try to do something like:

 my::package::Foo foo;
 foo.CopyFrom( *message );


 and I get a segfault in CopyFrom() because ultimately the following
 doesn't work (the pointer pFoo ends up being NULL down inside
 CopyFrom()/MergeFrom()):

 my::package::Foo* pFoo = dynamic_cast< my::package::Foo* >( message );


 It appears as though the derived type of message is not actually
 my::package::Foo, but instead google::protobuf::**DynamicMessage (or
 something like that), so naturally the dynamic_cast fails.  I was sure to
 observe the output of message->DebugString() and message->GetTypeName()
 which returned all the appropriate information.

 Is there any way to get a real my::package::Foo object from a dynamic
 one?


  --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/protobuf/-/iGRNOvXkgtEJ.
>
> To post to this group, send email to protobuf@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

2013-01-18 Thread m

The furthest I followed it was looking down into the implementation of 
CopyFrom() which calls MergeFrom().  Inside of MergeFrom() there's a spot 
where it calls something like "dynamic_cast_if_available" which returns 
NULL (failing to dynamic_cast).


On Thursday, January 17, 2013 10:20:13 PM UTC-8, Feng Xiao wrote:
>
> Glad that you found what works for you. What baffles me is why CopyFrom() 
> segfaults when given a DynamicMessage.  DynamicMessage can't be cast to 
> Foo, but foo.CopyFrom() gets to be working with it. Did you find why it 
> segfaults?
>
> On Friday, January 18, 2013 3:31:48 AM UTC+8, m wrote:
>>
>> Thanks for your reply.
>>
>> My application links against all the stub proto sources of the types I 
>> will be creating.  What I've found works is if I use the default(?) 
>> descriptor pool (google::protobuf::DescriptorPool::generated_pool()) and 
>> the default message factory 
>> (google::protobuf::MessageFactory::generated_factory()).  Given the type 
>> name and the content, I have a simple function that more or less does this:
>>
>> const gpb::Descriptor* descriptor = 
>> gpb::DescriptorPool::generated_pool()->FindMessageTypeByName( 
>> "my.package.Foo" );
>>
>>  
>>
>> gpb::MessageFactory* factory = gpb::MessageFactory::generated_factory();
>>
>>  
>>
>>
>> const gpb::Message* prototype = factory->GetPrototype( descriptor );
>>
>>  
>>
>>
>> gpb::Message* message = prototype->New();
>>
>>  
>>
>> gpb::Message* m = gpb::TextFormat::ParseFromString( "blah: \"some 
>> string\" bleh: 3", message );
>>
>>
>>
>>
>>
>> On Wednesday, January 16, 2013 4:15:53 PM UTC-8, m wrote:
>>>
>>> Hi All,
>>>
>>> I'm seeing an incompatibility between a dynamically generated 
>>> google::protobuf::Message (DynamicMessage?) created with a 
>>> google::protobuf::DynamicMessageFactory and a normal 
>>> google::protobuf::Message.
>>>
>>> What I'm running up against ultimately comes down to this: I can't 
>>> dynamic_cast a DynamicMessage to a known derived type of 
>>> google::protobuf::Message.  For example, let's say my proto file has the 
>>> following message:
>>>
>>> package my.package;
>>>
>>> messsage Foo
>>> {
>>>   string blah = 1;
>>>   uint32 bleh = 2;
>>> }
>>>
>>>
>>> and I successfully create a my::package::Foo with some code along the 
>>> lines of:
>>>
>>> const google::protobuf::Descriptor* descriptor = 
>>> myImporter.pool()->FindMessageTypeByName( 
>>> "my.package.Foo" );
>>>
>>> google::protobuf::Message* message = myDynamicMessageFactory.GetPrototype( 
>>> descriptor )->New();
>>>
>>>
>>> after populating message successfully with other commands not shown 
>>> here, I try to do something like:
>>>
>>> my::package::Foo foo;
>>> foo.CopyFrom( *message );
>>>
>>>
>>> and I get a segfault in CopyFrom() because ultimately the following 
>>> doesn't work (the pointer pFoo ends up being NULL down inside 
>>> CopyFrom()/MergeFrom()):
>>>
>>> my::package::Foo* pFoo = dynamic_cast< my::package::Foo* >( message );
>>>
>>>
>>> It appears as though the derived type of message is not actually 
>>> my::package::Foo, but instead google::protobuf::DynamicMessage (or 
>>> something like that), so naturally the dynamic_cast fails.  I was sure to 
>>> observe the output of message->DebugString() and message->GetTypeName() 
>>> which returned all the appropriate information.
>>>
>>> Is there any way to get a real my::package::Foo object from a dynamic 
>>> one?
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/protobuf/-/iGRNOvXkgtEJ.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

2013-01-17 Thread Feng Xiao

Glad that you found what works for you. What baffles me is why CopyFrom() 
segfaults when given a DynamicMessage.  DynamicMessage can't be cast to 
Foo, but foo.CopyFrom() gets to be working with it. Did you find why it 
segfaults?

On Friday, January 18, 2013 3:31:48 AM UTC+8, m wrote:
>
> Thanks for your reply.
>
> My application links against all the stub proto sources of the types I 
> will be creating.  What I've found works is if I use the default(?) 
> descriptor pool (google::protobuf::DescriptorPool::generated_pool()) and 
> the default message factory 
> (google::protobuf::MessageFactory::generated_factory()).  Given the type 
> name and the content, I have a simple function that more or less does this:
>
> const gpb::Descriptor* descriptor = 
> gpb::DescriptorPool::generated_pool()->FindMessageTypeByName( 
> "my.package.Foo" );
>
>  
>
> gpb::MessageFactory* factory = gpb::MessageFactory::generated_factory();
>
>  
>
>
> const gpb::Message* prototype = factory->GetPrototype( descriptor );
>
>  
>
>
> gpb::Message* message = prototype->New();
>
>  
>
> gpb::Message* m = gpb::TextFormat::ParseFromString( "blah: \"some string\" 
> bleh: 3", message );
>
>
>
>
>
> On Wednesday, January 16, 2013 4:15:53 PM UTC-8, m wrote:
>>
>> Hi All,
>>
>> I'm seeing an incompatibility between a dynamically generated 
>> google::protobuf::Message (DynamicMessage?) created with a 
>> google::protobuf::DynamicMessageFactory and a normal 
>> google::protobuf::Message.
>>
>> What I'm running up against ultimately comes down to this: I can't 
>> dynamic_cast a DynamicMessage to a known derived type of 
>> google::protobuf::Message.  For example, let's say my proto file has the 
>> following message:
>>
>> package my.package;
>>
>> messsage Foo
>> {
>>   string blah = 1;
>>   uint32 bleh = 2;
>> }
>>
>>
>> and I successfully create a my::package::Foo with some code along the 
>> lines of:
>>
>> const google::protobuf::Descriptor* descriptor = 
>> myImporter.pool()->FindMessageTypeByName( 
>> "my.package.Foo" );
>>
>> google::protobuf::Message* message = myDynamicMessageFactory.GetPrototype( 
>> descriptor )->New();
>>
>>
>> after populating message successfully with other commands not shown 
>> here, I try to do something like:
>>
>> my::package::Foo foo;
>> foo.CopyFrom( *message );
>>
>>
>> and I get a segfault in CopyFrom() because ultimately the following 
>> doesn't work (the pointer pFoo ends up being NULL down inside 
>> CopyFrom()/MergeFrom()):
>>
>> my::package::Foo* pFoo = dynamic_cast< my::package::Foo* >( message );
>>
>>
>> It appears as though the derived type of message is not actually 
>> my::package::Foo, but instead google::protobuf::DynamicMessage (or 
>> something like that), so naturally the dynamic_cast fails.  I was sure to 
>> observe the output of message->DebugString() and message->GetTypeName() 
>> which returned all the appropriate information.
>>
>> Is there any way to get a real my::package::Foo object from a dynamic 
>> one?
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/protobuf/-/sC2xjV3x8F0J.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

2013-01-17 Thread m

Sorry, there's a typo on that last line.  It should be:

gpb::TextFormat::ParseFromString( "blah: \"some string\" bleh: 3", message 
);




On Thursday, January 17, 2013 11:31:48 AM UTC-8, m wrote:
>
> Thanks for your reply.
>
> My application links against all the stub proto sources of the types I 
> will be creating.  What I've found works is if I use the default(?) 
> descriptor pool (google::protobuf::DescriptorPool::generated_pool()) and 
> the default message factory 
> (google::protobuf::MessageFactory::generated_factory()).  Given the type 
> name and the content, I have a simple function that more or less does this:
>
> const gpb::Descriptor* descriptor = 
> gpb::DescriptorPool::generated_pool()->FindMessageTypeByName( 
> "my.package.Foo" );
>
>  
>
> gpb::MessageFactory* factory = gpb::MessageFactory::generated_factory();
>
>  
>
>
> const gpb::Message* prototype = factory->GetPrototype( descriptor );
>
>  
>
>
> gpb::Message* message = prototype->New();
>
>  
>
> gpb::Message* m = gpb::TextFormat::ParseFromString( "blah: \"some string\" 
> bleh: 3", message );
>
>
>
>
>
> On Wednesday, January 16, 2013 4:15:53 PM UTC-8, m wrote:
>>
>> Hi All,
>>
>> I'm seeing an incompatibility between a dynamically generated 
>> google::protobuf::Message (DynamicMessage?) created with a 
>> google::protobuf::DynamicMessageFactory and a normal 
>> google::protobuf::Message.
>>
>> What I'm running up against ultimately comes down to this: I can't 
>> dynamic_cast a DynamicMessage to a known derived type of 
>> google::protobuf::Message.  For example, let's say my proto file has the 
>> following message:
>>
>> package my.package;
>>
>> messsage Foo
>> {
>>   string blah = 1;
>>   uint32 bleh = 2;
>> }
>>
>>
>> and I successfully create a my::package::Foo with some code along the 
>> lines of:
>>
>> const google::protobuf::Descriptor* descriptor = 
>> myImporter.pool()->FindMessageTypeByName( 
>> "my.package.Foo" );
>>
>> google::protobuf::Message* message = myDynamicMessageFactory.GetPrototype( 
>> descriptor )->New();
>>
>>
>> after populating message successfully with other commands not shown 
>> here, I try to do something like:
>>
>> my::package::Foo foo;
>> foo.CopyFrom( *message );
>>
>>
>> and I get a segfault in CopyFrom() because ultimately the following 
>> doesn't work (the pointer pFoo ends up being NULL down inside 
>> CopyFrom()/MergeFrom()):
>>
>> my::package::Foo* pFoo = dynamic_cast< my::package::Foo* >( message );
>>
>>
>> It appears as though the derived type of message is not actually 
>> my::package::Foo, but instead google::protobuf::DynamicMessage (or 
>> something like that), so naturally the dynamic_cast fails.  I was sure to 
>> observe the output of message->DebugString() and message->GetTypeName() 
>> which returned all the appropriate information.
>>
>> Is there any way to get a real my::package::Foo object from a dynamic 
>> one?
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/protobuf/-/IBJoFdPF1xoJ.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

2013-01-17 Thread m

Thanks for your reply.

My application links against all the stub proto sources of the types I will 
be creating.  What I've found works is if I use the default(?) descriptor 
pool (google::protobuf::DescriptorPool::generated_pool()) and the default 
message factory (google::protobuf::MessageFactory::generated_factory()). 
 Given the type name and the content, I have a simple function that more or 
less does this:

const gpb::Descriptor* descriptor = 
gpb::DescriptorPool::generated_pool()->FindMessageTypeByName( 
"my.package.Foo" );

 

gpb::MessageFactory* factory = gpb::MessageFactory::generated_factory();

 


const gpb::Message* prototype = factory->GetPrototype( descriptor );

 


gpb::Message* message = prototype->New();

 

gpb::Message* m = gpb::TextFormat::ParseFromString( "blah: \"some string\" 
bleh: 3", message );





On Wednesday, January 16, 2013 4:15:53 PM UTC-8, m wrote:
>
> Hi All,
>
> I'm seeing an incompatibility between a dynamically generated 
> google::protobuf::Message (DynamicMessage?) created with a 
> google::protobuf::DynamicMessageFactory and a normal 
> google::protobuf::Message.
>
> What I'm running up against ultimately comes down to this: I can't 
> dynamic_cast a DynamicMessage to a known derived type of 
> google::protobuf::Message.  For example, let's say my proto file has the 
> following message:
>
> package my.package;
>
> messsage Foo
> {
>   string blah = 1;
>   uint32 bleh = 2;
> }
>
>
> and I successfully create a my::package::Foo with some code along the 
> lines of:
>
> const google::protobuf::Descriptor* descriptor = 
> myImporter.pool()->FindMessageTypeByName( 
> "my.package.Foo" );
>
> google::protobuf::Message* message = myDynamicMessageFactory.GetPrototype( 
> descriptor )->New();
>
>
> after populating message successfully with other commands not shown here, 
> I try to do something like:
>
> my::package::Foo foo;
> foo.CopyFrom( *message );
>
>
> and I get a segfault in CopyFrom() because ultimately the following 
> doesn't work (the pointer pFoo ends up being NULL down inside 
> CopyFrom()/MergeFrom()):
>
> my::package::Foo* pFoo = dynamic_cast< my::package::Foo* >( message );
>
>
> It appears as though the derived type of message is not actually 
> my::package::Foo, but instead google::protobuf::DynamicMessage (or 
> something like that), so naturally the dynamic_cast fails.  I was sure to 
> observe the output of message->DebugString() and message->GetTypeName() 
> which returned all the appropriate information.
>
> Is there any way to get a real my::package::Foo object from a dynamic one?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/protobuf/-/-Q3WjR4djmsJ.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

2013-01-16 Thread Feng Xiao



On Thursday, January 17, 2013 8:15:53 AM UTC+8, m wrote:
>
> Hi All,
>
> I'm seeing an incompatibility between a dynamically generated 
> google::protobuf::Message (DynamicMessage?) created with a 
> google::protobuf::DynamicMessageFactory and a normal 
> google::protobuf::Message.
>
> What I'm running up against ultimately comes down to this: I can't 
> dynamic_cast a DynamicMessage to a known derived type of 
> google::protobuf::Message.  For example, let's say my proto file has the 
> following message:
>
> package my.package;
>
> messsage Foo
> {
>   string blah = 1;
>   uint32 bleh = 2;
> }
>
>
> and I successfully create a my::package::Foo with some code along the 
> lines of:
>
> const google::protobuf::Descriptor* descriptor = 
> myImporter.pool()->FindMessageTypeByName( 
> "my.package.Foo" );
>
> google::protobuf::Message* message = myDynamicMessageFactory.GetPrototype( 
> descriptor )->New();
>
>
> after populating message successfully with other commands not shown here, 
> I try to do something like:
>
> my::package::Foo foo;
> foo.CopyFrom( *message );
>
>
> and I get a segfault in CopyFrom() because ultimately the following 
> doesn't work (the pointer pFoo ends up being NULL down inside 
> CopyFrom()/MergeFrom()):
>
CopyFrom() should be able to copy a DynamicMessage to a generated message 
if they share the same descriptor.
Can you post the whole generated method where the segfault happens?
 

>
> my::package::Foo* pFoo = dynamic_cast< my::package::Foo* >( message );
>
>
> It appears as though the derived type of message is not actually 
> my::package::Foo, but instead google::protobuf::DynamicMessage (or 
> something like that), so naturally the dynamic_cast fails.  I was sure to 
> observe the output of message->DebugString() and message->GetTypeName() 
> which returned all the appropriate information.
>
> Is there any way to get a real my::package::Foo object from a dynamic one?
>
 

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/protobuf/-/bhtIMTO3PhUJ.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Re: [protobuf] Re: Dynamic Message

2010-11-05 Thread Jason Hsueh

On Fri, Nov 5, 2010 at 3:26 PM, AdamM  wrote:

> Is there a way to return the entire extension part of the message into
> a separate message like:
>
> message Foo {
>  extensions 100 to 199;
> }
>
>
> message Baz {
>  extend Foo {
>optional int32 bar = 126;
>  }
> }
>
> In C++ Code:
>
> Foo foo;
> foo.SetExtension(Baz::bar, 15);
>
> Elsewhere in code, obviously the code below does not work but is there
> a way to do something like that?


> Baz baz;
> baz = foo.GetExtension(Baz);
>

No, you can't do that. In your .proto definition, Baz is just a container
for the extension identifier. There is no relationship between the
extensions and the Baz message type. You could have written your proto
definition as:

message Foo {
 extensions 100 to 199;
}

extend Foo {
  optional int32 bar = 126;
}

And done:
Foo foo;
foo.SetExtension(bar, 15);
int value = foo.GetExtension(bar);   // equals 15

If you want to use a message type, do:

message Baz {
  optional int32 bar = 1;
  ...
}
extend Foo {
  optional Baz baz_extension = 126;
}

To access the message in the extensions:
Foo foo;
Baz* baz = foo.MutableExtension(baz_extension);
const Baz& baz = foo.GetExtension(baz_extension);


>
>
>
>
> On Nov 5, 5:28 pm, Daniel Wright  wrote:
> > On Fri, Nov 5, 2010 at 2:12 PM, AdamM  wrote:
> > > Thank you Daniel is was not aware of this feature in PB I will give it
> > > a try.
> >
> > There is a slight gain for smaller numbers, but it's small enough that
> it's
> > not worth the maintenance headache of trying to choose unique small
> numbers.
> >  Basically, tags with numbers less than 16 use 1 byte.  16 to 2048 use
> two
> > bytes, 2048 to 262144 use 3 bytes, 262144 to 33554432 use 4 bytes etc
> (you
> > get 7 bits per byte, except for the first byte which only gets 4 bits.
> http://code.google.com/apis/protocolbuffers/docs/encoding.htmlhas the
> > details).
> >
> > Note that the actual "extensions 100 to 10;" line in the .proto
> file
> > costs nothing -- the gain I'm talking about above is when you encode a
> > message with a given field number.
> >
> > One question though is there any optimization gain you get from using
> >
> >
> >
> >
> >
> >
> >
> > > "extensions 100 to 200;" over "extensions 100 to 10;"?
> >
> > > On Nov 5, 3:21 pm, Daniel Wright  wrote:
> > > > This is exactly what extensions are for -- seehttp://
> > > code.google.com/apis/protocolbuffers/docs/proto.html#extensions
> >
> > > > It would look something like:
> >
> > > > message BaseMessage {
> > > >   required MsgType type = 1;
> > > >   extensions 100 to 10;
> >
> > > > }
> >
> > > > Then each module would have a message like:
> >
> > > > message Msg1 {
> > > >   extend BaseMessage {
> > > > optional Msg1 msg1 = 
> > > >   }
> > > >   required int32 field = 1;
> >
> > > > }
> >
> > > > Then the main program can pass the entire BaseMessage to the right
> module
> > > > based on type, and the module can retrieve the parsed extension.
> >
> > > > On Fri, Nov 5, 2010 at 10:31 AM, AdamM 
> wrote:
> > > > > Hello PB Group,
> >
> > > > > I am programming a group of programs in C++ that use PB to
> > > > > communicate. In my first version of the program I was using a
> .proto
> > > > > file that looked similar to the example 1 below. I would then run a
> > > > > switch statement on a MsgType and create the proper message.
> >
> > > > > I am now starting to write my second version of the program to
> include
> > > > > a plugin module architecture. My program calls for a core program
> and
> > > > > then multiple modules that are written against a base module. Well
> in
> > > > > my core program I get packets over the network and then parse them
> > > > > info a PB Message.
> >
> > > > > I would like a way to have some sort of Base Message that the my
> core
> > > > > program would use to parse with the  base message would contain a
> > > > > packet packet operation code and the data for the actual message
> > > > > structure. I want to program it so the Core program has no idea
> what
> > > > > the actual message structure is. It would pass it to the respective
> > > > > module based on the operation code who would then  parse the actual
> > > > > message structure because it knows what that structure should be.
> >
> > > > > Does anyone have any suggestions how to do this? Any help would be
> > > > > much appreciated.
> >
> > > > > Example 1.
> >
> > > > > enum MsgType {
> > > > >   MSG1,
> > > > >   MSG2,
> > > > >   MSG3
> > > > > }
> >
> > > > > Message Msg1 {
> > > > >   required int32 field = 1 ;
> > > > > }
> >
> > > > > Message Msg2 {
> > > > >   required int32 field = 1 ;
> > > > > }
> >
> > > > > Message Msg3 {
> > > > >   required int32 field = 1 ;
> > > > > }
> >
> > > > > Message BaseMessage {
> > > > >   required MsgType type = 1 ;
> > > > >   optional Msg1 = 2 ;
> > > > >   optional Msg2 = 3 ;
> > > > >   optional Msg3 = 4 ;
> > > > > }
> >
> > > > > --
> > > > > You received this message because you are subscribe

[protobuf] Re: Dynamic Message

2010-11-05 Thread AdamM

Is there a way to return the entire extension part of the message into
a separate message like:

message Foo {
  extensions 100 to 199;
}


message Baz {
  extend Foo {
optional int32 bar = 126;
  }
}

In C++ Code:

Foo foo;
foo.SetExtension(Baz::bar, 15);

Elsewhere in code, obviously the code below does not work but is there
a way to do something like that?

Baz baz;
baz = foo.GetExtension(Baz);




On Nov 5, 5:28 pm, Daniel Wright  wrote:
> On Fri, Nov 5, 2010 at 2:12 PM, AdamM  wrote:
> > Thank you Daniel is was not aware of this feature in PB I will give it
> > a try.
>
> There is a slight gain for smaller numbers, but it's small enough that it's
> not worth the maintenance headache of trying to choose unique small numbers.
>  Basically, tags with numbers less than 16 use 1 byte.  16 to 2048 use two
> bytes, 2048 to 262144 use 3 bytes, 262144 to 33554432 use 4 bytes etc (you
> get 7 bits per byte, except for the first byte which only gets 4 
> bits.http://code.google.com/apis/protocolbuffers/docs/encoding.htmlhas the
> details).
>
> Note that the actual "extensions 100 to 10;" line in the .proto file
> costs nothing -- the gain I'm talking about above is when you encode a
> message with a given field number.
>
> One question though is there any optimization gain you get from using
>
>
>
>
>
>
>
> > "extensions 100 to 200;" over "extensions 100 to 10;"?
>
> > On Nov 5, 3:21 pm, Daniel Wright  wrote:
> > > This is exactly what extensions are for -- seehttp://
> > code.google.com/apis/protocolbuffers/docs/proto.html#extensions
>
> > > It would look something like:
>
> > > message BaseMessage {
> > >   required MsgType type = 1;
> > >   extensions 100 to 10;
>
> > > }
>
> > > Then each module would have a message like:
>
> > > message Msg1 {
> > >   extend BaseMessage {
> > >     optional Msg1 msg1 = 
> > >   }
> > >   required int32 field = 1;
>
> > > }
>
> > > Then the main program can pass the entire BaseMessage to the right module
> > > based on type, and the module can retrieve the parsed extension.
>
> > > On Fri, Nov 5, 2010 at 10:31 AM, AdamM  wrote:
> > > > Hello PB Group,
>
> > > > I am programming a group of programs in C++ that use PB to
> > > > communicate. In my first version of the program I was using a .proto
> > > > file that looked similar to the example 1 below. I would then run a
> > > > switch statement on a MsgType and create the proper message.
>
> > > > I am now starting to write my second version of the program to include
> > > > a plugin module architecture. My program calls for a core program and
> > > > then multiple modules that are written against a base module. Well in
> > > > my core program I get packets over the network and then parse them
> > > > info a PB Message.
>
> > > > I would like a way to have some sort of Base Message that the my core
> > > > program would use to parse with the  base message would contain a
> > > > packet packet operation code and the data for the actual message
> > > > structure. I want to program it so the Core program has no idea what
> > > > the actual message structure is. It would pass it to the respective
> > > > module based on the operation code who would then  parse the actual
> > > > message structure because it knows what that structure should be.
>
> > > > Does anyone have any suggestions how to do this? Any help would be
> > > > much appreciated.
>
> > > > Example 1.
>
> > > > enum MsgType {
> > > >   MSG1,
> > > >   MSG2,
> > > >   MSG3
> > > > }
>
> > > > Message Msg1 {
> > > >   required int32 field = 1 ;
> > > > }
>
> > > > Message Msg2 {
> > > >   required int32 field = 1 ;
> > > > }
>
> > > > Message Msg3 {
> > > >   required int32 field = 1 ;
> > > > }
>
> > > > Message BaseMessage {
> > > >   required MsgType type = 1 ;
> > > >   optional Msg1 = 2 ;
> > > >   optional Msg2 = 3 ;
> > > >   optional Msg3 = 4 ;
> > > > }
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "Protocol Buffers" group.
> > > > To post to this group, send email to proto...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > protobuf+unsubscr...@googlegroups.com > > >  om>
> > 
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/protobuf?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to proto...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com > om>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this gr

Re: [protobuf] Re: Dynamic Message

2010-11-05 Thread Daniel Wright

On Fri, Nov 5, 2010 at 2:12 PM, AdamM  wrote:

> Thank you Daniel is was not aware of this feature in PB I will give it
> a try.
>

There is a slight gain for smaller numbers, but it's small enough that it's
not worth the maintenance headache of trying to choose unique small numbers.
 Basically, tags with numbers less than 16 use 1 byte.  16 to 2048 use two
bytes, 2048 to 262144 use 3 bytes, 262144 to 33554432 use 4 bytes etc (you
get 7 bits per byte, except for the first byte which only gets 4 bits.
http://code.google.com/apis/protocolbuffers/docs/encoding.html has the
details).

Note that the actual "extensions 100 to 10;" line in the .proto file
costs nothing -- the gain I'm talking about above is when you encode a
message with a given field number.

One question though is there any optimization gain you get from using
> "extensions 100 to 200;" over "extensions 100 to 10;"?
>
> On Nov 5, 3:21 pm, Daniel Wright  wrote:
> > This is exactly what extensions are for -- seehttp://
> code.google.com/apis/protocolbuffers/docs/proto.html#extensions
> >
> > It would look something like:
> >
> > message BaseMessage {
> >   required MsgType type = 1;
> >   extensions 100 to 10;
> >
> > }
> >
> > Then each module would have a message like:
> >
> > message Msg1 {
> >   extend BaseMessage {
> > optional Msg1 msg1 = 
> >   }
> >   required int32 field = 1;
> >
> > }
> >
> > Then the main program can pass the entire BaseMessage to the right module
> > based on type, and the module can retrieve the parsed extension.
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Nov 5, 2010 at 10:31 AM, AdamM  wrote:
> > > Hello PB Group,
> >
> > > I am programming a group of programs in C++ that use PB to
> > > communicate. In my first version of the program I was using a .proto
> > > file that looked similar to the example 1 below. I would then run a
> > > switch statement on a MsgType and create the proper message.
> >
> > > I am now starting to write my second version of the program to include
> > > a plugin module architecture. My program calls for a core program and
> > > then multiple modules that are written against a base module. Well in
> > > my core program I get packets over the network and then parse them
> > > info a PB Message.
> >
> > > I would like a way to have some sort of Base Message that the my core
> > > program would use to parse with the  base message would contain a
> > > packet packet operation code and the data for the actual message
> > > structure. I want to program it so the Core program has no idea what
> > > the actual message structure is. It would pass it to the respective
> > > module based on the operation code who would then  parse the actual
> > > message structure because it knows what that structure should be.
> >
> > > Does anyone have any suggestions how to do this? Any help would be
> > > much appreciated.
> >
> > > Example 1.
> >
> > > enum MsgType {
> > >   MSG1,
> > >   MSG2,
> > >   MSG3
> > > }
> >
> > > Message Msg1 {
> > >   required int32 field = 1 ;
> > > }
> >
> > > Message Msg2 {
> > >   required int32 field = 1 ;
> > > }
> >
> > > Message Msg3 {
> > >   required int32 field = 1 ;
> > > }
> >
> > > Message BaseMessage {
> > >   required MsgType type = 1 ;
> > >   optional Msg1 = 2 ;
> > >   optional Msg2 = 3 ;
> > >   optional Msg3 = 4 ;
> > > }
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Protocol Buffers" group.
> > > To post to this group, send email to proto...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > protobuf+unsubscr...@googlegroups.com
> 
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/protobuf?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Dynamic Message

2010-11-05 Thread AdamM

Thank you Daniel is was not aware of this feature in PB I will give it
a try.

One question though is there any optimization gain you get from using
"extensions 100 to 200;" over "extensions 100 to 10;"?

On Nov 5, 3:21 pm, Daniel Wright  wrote:
> This is exactly what extensions are for -- 
> seehttp://code.google.com/apis/protocolbuffers/docs/proto.html#extensions
>
> It would look something like:
>
> message BaseMessage {
>   required MsgType type = 1;
>   extensions 100 to 10;
>
> }
>
> Then each module would have a message like:
>
> message Msg1 {
>   extend BaseMessage {
>     optional Msg1 msg1 = 
>   }
>   required int32 field = 1;
>
> }
>
> Then the main program can pass the entire BaseMessage to the right module
> based on type, and the module can retrieve the parsed extension.
>
>
>
>
>
>
>
> On Fri, Nov 5, 2010 at 10:31 AM, AdamM  wrote:
> > Hello PB Group,
>
> > I am programming a group of programs in C++ that use PB to
> > communicate. In my first version of the program I was using a .proto
> > file that looked similar to the example 1 below. I would then run a
> > switch statement on a MsgType and create the proper message.
>
> > I am now starting to write my second version of the program to include
> > a plugin module architecture. My program calls for a core program and
> > then multiple modules that are written against a base module. Well in
> > my core program I get packets over the network and then parse them
> > info a PB Message.
>
> > I would like a way to have some sort of Base Message that the my core
> > program would use to parse with the  base message would contain a
> > packet packet operation code and the data for the actual message
> > structure. I want to program it so the Core program has no idea what
> > the actual message structure is. It would pass it to the respective
> > module based on the operation code who would then  parse the actual
> > message structure because it knows what that structure should be.
>
> > Does anyone have any suggestions how to do this? Any help would be
> > much appreciated.
>
> > Example 1.
>
> > enum MsgType {
> >   MSG1,
> >   MSG2,
> >   MSG3
> > }
>
> > Message Msg1 {
> >   required int32 field = 1 ;
> > }
>
> > Message Msg2 {
> >   required int32 field = 1 ;
> > }
>
> > Message Msg3 {
> >   required int32 field = 1 ;
> > }
>
> > Message BaseMessage {
> >   required MsgType type = 1 ;
> >   optional Msg1 = 2 ;
> >   optional Msg2 = 3 ;
> >   optional Msg3 = 4 ;
> > }
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to proto...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com > om>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Dynamic Message

2010-11-05 Thread AdamM

This is the way I initially thought to do it but the extensions seems
like a  much better idea. Is there any benefit of using an opaque data
method over extensions.

On Nov 5, 2:15 pm, Jon Parise  wrote:
> Hi Adam,
>
> I needed to do something similar on a previous project.  I stored the
> serialized version of the type-specific message as opaque data ("bytes") in
> an outer enveloping message.
>
> message Envelope
> {
>     required MsgType type = 1;
>     required bytes data = 2;
>
> }
>
> Then you can create any type of message type hierarchy you like.  You simply
> write the serialized version of those messages into the 'data' field above
> and  switch based on the 'type' field.
>
> There are two immediate downsides to this approach: 1) a few bytes of
> serialization overhead; and 2) the embedded message data is treated
> opaquely, so it's slightly harder to inspect.
>
> — *Jon*
>
>
>
>
>
>
>
> On Fri, Nov 5, 2010 at 10:31 AM, AdamM  wrote:
> > Hello PB Group,
>
> > I am programming a group of programs in C++ that use PB to
> > communicate. In my first version of the program I was using a .proto
> > file that looked similar to the example 1 below. I would then run a
> > switch statement on a MsgType and create the proper message.
>
> > I am now starting to write my second version of the program to include
> > a plugin module architecture. My program calls for a core program and
> > then multiple modules that are written against a base module. Well in
> > my core program I get packets over the network and then parse them
> > info a PB Message.
>
> > I would like a way to have some sort of Base Message that the my core
> > program would use to parse with the  base message would contain a
> > packet packet operation code and the data for the actual message
> > structure. I want to program it so the Core program has no idea what
> > the actual message structure is. It would pass it to the respective
> > module based on the operation code who would then  parse the actual
> > message structure because it knows what that structure should be.
>
> > Does anyone have any suggestions how to do this? Any help would be
> > much appreciated.
>
> > Example 1.
>
> > enum MsgType {
> >   MSG1,
> >   MSG2,
> >   MSG3
> > }
>
> > Message Msg1 {
> >   required int32 field = 1 ;
> > }
>
> > Message Msg2 {
> >   required int32 field = 1 ;
> > }
>
> > Message Msg3 {
> >   required int32 field = 1 ;
> > }
>
> > Message BaseMessage {
> >   required MsgType type = 1 ;
> >   optional Msg1 = 2 ;
> >   optional Msg2 = 3 ;
> >   optional Msg3 = 4 ;
> > }
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to proto...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com > om>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Re: [protobuf] Re: Dynamic message schema verification

[protobuf] Re: Dynamic message schema verification

Re: [protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

[protobuf] Re: Dynamic Message and google::protobuf::Message incompatibility

Re: [protobuf] Re: Dynamic Message

[protobuf] Re: Dynamic Message

Re: [protobuf] Re: Dynamic Message

[protobuf] Re: Dynamic Message

[protobuf] Re: Dynamic Message

13 matches

Site Navigation

Mail list logo

Footer information