I somehow understand what you mean but still I lack in experience with it.
I tried to switch to descriptor database but still I got some problems.
m_strProtoFile = strFile;
// Build the descriptor pool
m_bConstructed = ParseProtoFile(&m_ProtoFileDescr);
m_Pool = new DescriptorPool(&m_ProtoDescrDatabase);
strWireFormat, std::string strType)
Descriptor *descriptor = (Descriptor
Message *message = m_MessageFactory.GetPrototype(descriptor)->New();
if (descriptor == NULL)
sprintf(szError, "Unknown data type %s!", strType.c_str());
bool bFlag = message->ParseFromString(strWireFormat);
bool C_ProtoDecoder::ParseProtoFile(FileDescriptorProto *result)
int file_descriptor = open(m_strProtoFile.c_str(), O_RDONLY);
if (file_descriptor == -1)
sprintf(szError, "Invalid proto file \"%s\"!",
io::Tokenizer tokenizer(&stream, &errCollector);
return parser.Parse(&tokenizer, result);
I have used SimpleDescriptorDatabase since it looked like it has already
implemented and its covering what I will be requiring from it (or at least
I think it does)
Everything is fine until I try to get descriptor by FindMessageTypeByName
from pool. It returns null. Am I committing some steps?
On Tuesday, 2 June 2015 19:49:53 UTC+2, Feng Xiao wrote:
> On Mon, Jun 1, 2015 at 9:55 PM, Jan Kyjovský <jan.ky...@tieto.com
>> Hi again,
>> As I have stated before I am done with decoding, but now I am solving
>> different type of problem. As I have mentioned before imports may prove
>> problematic to our implementation.
>> Let me describe use-case how it will be used. There will be configuration
>> stating for which data (message number, specific field) will be applied
>> which proto file and structure (data type). Therefore there is no knowledge
>> about other proto files up until now. In run time data are fetched and
>> shipped to decoder. In current implementation is specified proto file
>> loaded and specific type used for decoding. That much is clear and works.
>> But if some parts of structures are imported. It will fail. That much is
>> clear that using just one file descriptor will be not enough as you have
>> mentioned earlier.
>> That leads to your proposition (posted earlier) to use
>> DescriptorDatabase. I have looked on implementation of classes derived from
>> DscriptorDatabase. I am more or less able to provide directory for
>> SourceTree, but that doesn't answer question about import. I mean since I
>> am aware of only one proto file. Is import done automatically or other
>> files has to be also included manually into database?
>> Another question I have is bout order of operations. You mentioned that I
>> have to first call FindFileByName() before callingFindMessageTypeByName().
>> That may be problem since I am not aware in which proto file may be located.
>> Also I have noticed in code note that proto files with types used in
>> other proto files have to be "loaded" first. So is there any way how to
>> ensure right order of loading?
> Most of the work is done by DescriptorPool. Basically when you call
> FindFileByName() on a .proto file that is not yet loaded into the pool,
> DescriptorPool will call FindFileByName() on its underlying
> DescriptorDatabase to get the FileDescriptorProto for file. Then
> DescriptorPool will check the imports of this FileDescriptorPool. If it
> finds unsatisfied imports (i.e., files imported but not yet in the pool),
> it will issue FindFileByName() to the DescriptorDatabase again for these
> So basically DescriptorDatabase only needs to know how to load a single
> .proto file, while DescriptorPool will take care of the imports and
> Depending on what DescriptorDatabase you are using, you may or may not
> need to call FindFileByName() first. If the DescriptorDatabase has
> implement FindFileContainingSymbol, then calling
> DescriptorPool::FindMessageTypeByName() directly will be able to find the
> file using this method. If not (the case with
> SourceTreeDescriptorDatabase), FindFileByName() must be called first. As
> DescriptorPool will be able to find imports by itself, you don't need to
> call FindFileByName() for every file, but just the file that you actually
> need to use.
>> I hope my question are not too strange but I my knowledge about google
>> protocol buffers are a bit limited.
>> 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
>> To post to this group, send email to prot...@googlegroups.com
>> Visit this group at http://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
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 post to this group, send email to firstname.lastname@example.org.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.