Re: Storing complex graphs of objects?

[Kenton Varda]

You could treat the protobuf classes as private implemnetation helpers.
 Your public interface would have methods like you describe, and internally
they'd just copy the object's state into a protocol buffer and then
serialize it.

On Fri, Mar 27, 2009 at 2:32 AM, Paul Runyan wrote:

>  Hi Kenton -
>
> Thanks for your help.  Obviously defining message types in proto files is
> crucial for being able to exchange messages between different languages.
> However, as a substitute for Java serialisation having to specify message
> types in separate files from the source files seems less than ideal.
>
> What I was thinking of was more along the lines of adding methods to each
> object to be serialised via PB that look like the methods on the classes the
> PB compiler generates --- writeTo() and parseFrom().  These would work
> analogously to the way that writeObject() and readObject() for normal
> serialisation, but by trading away the unrestricted polymorhism that this
> type of application doesn't need it allow it to write ints rather than class
> names to distinguish types and would hopefully also gain from the extra
> efficiencies of CodedInputStream and CodedOutputStream.
>
> Best regards,
>
> Paul
>
> --
> Find car news, reviews and more Looking to change your car this 
> year?
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

RE: Storing complex graphs of objects?

[Paul Runyan]

Hi Kenton -

 

Thanks for your help.  Obviously defining message types in proto files is 
crucial for being able to exchange messages between different languages.  
However, as a substitute for Java serialisation having to specify message types 
in separate files from the source files seems less than ideal.  

 

What I was thinking of was more along the lines of adding methods to each 
object to be serialised via PB that look like the methods on the classes the PB 
compiler generates --- writeTo() and parseFrom().  These would work analogously 
to the way that writeObject() and readObject() for normal serialisation, but by 
trading away the unrestricted polymorhism that this type of application doesn't 
need it allow it to write ints rather than class names to distinguish types and 
would hopefully also gain from the extra efficiencies of CodedInputStream and 
CodedOutputStream.

 

Best regards,

 

Paul

_
Looking to change your car this year? Find car news, reviews and more 
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Storing complex graphs of objects?

[Kenton Varda]

To store a DAG (or a cyclic graph, for that matter) you would need to come
up with some sort of identifier system for objects and then refer to objects
by their identifier instead, so that multiple locations can refer to the
same object without copying it.  Example:
  message Graph {
repeated Node node = 1;
  }

  message Node {
// Indexes of children within the containing graph.
repeated int32 child = 1;
  }

Or maybe:

  message Node {
required int32 id = 1;
repeated int32 child_id = 2;
  }

Using ids like this makes it easier to remove nodes from the graph but makes
it harder to look up children (you'd need to maintain a separate lookup
table).

To store multiple types, you'd either have to make Node extendable or you'd
have to have a separate repeated field in Graph for each type.

Yeah, it's not as easy as Java serialization, but it will be much faster and
smaller.

On Wed, Mar 25, 2009 at 3:04 PM,  wrote:

>
> I have an application in which I serialise graphs of Java objects and
> store them to disk.
>
> These graphs can be quite deep.  However, they will never contain
> cycles and all the objects in them will always be pure value
> objects.
>
> The set of classes that need to be stored does have to be able to grow
> over the lifetime of the persistence storage.  However its not a
> requirement for existing graph types to be able to support new subnode
> types via polymorphism.  That is, the set of types that can be stored
> beneath a particular root object type are fixed, new types of value
> objects will only ever be added under new root types.
>
> The application needs to store these graphs quickly and compactly.
> Currently it's using Java serialisation.  However because Java
> serialisation is intended to support full polymorphism it uses a lot
> of space storing classname information, which for this application is
> redundant.  It seems like Protocol Buffers might be useful here but
> storing complex graphs of objects using protocol buffers looks
> unwieldy and error prone.
>
> I was just wondering whether anyone has had experience using PB for
> storing complex graphs of objects.
>
> Thanks,
>
> Paul
>
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---