tonynhan / protobuf-net

Automatically exported from code.google.com/p/protobuf-net
Other
0 stars 0 forks source link

Issue with large object graph #82

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Hi Marc

First of all, thanks very much for putting effort into protobuf-net. It's a 
great engine!

I have a problem with a very large object graph I'm trying to serialize. 
Sometimes, a collection of a certain type just won't serialize. I have 
tried many different ways of tagging my properties to no avail.

4 out of 7 instances of Collection<UploadSvartype> (sorry for the mixed 
language names) get serialized and deserialised fine. But the last 3 are 
stubborn.

Smaller object graphs seem to work better.

I have included a test solution to make it easier for you to reproduce. The 
test is called Can_serialize_and_deserialize_as_protobuffer in 
IntegrationTests.cs

I really appreciate any help.

Regards,
Søren
sos at ditmer dot com

Original issue reported on code.google.com by badmot...@gmail.com on 16 Nov 2009 at 1:42

Attachments:

GoogleCodeExporter commented 8 years ago
Example doesn't compile; am I missing something?

C:\Users\mgravell\Desktop\Bug\Protobuf-issue\IntegrationTests.cs(28,10): error 
CS1061: 'Ditmer.Everest.Sporgeskema.Skema' does not contain a definition for 
'DeserializeXml' and no extension method 'DeserializeXml' accepting a first 
argument 
of type 'Ditmer.Everest.Sporgeskema.Skema' could be found (are you missing a 
using 
directive or an assembly reference?)
C:\Users\mgravell\Desktop\Bug\Protobuf-issue\IntegrationTests.cs(31,35): error 
CS1061: 'Ditmer.Everest.Sporgeskema.Skema' does not contain a definition for 
'SerializeXml' and no extension method 'SerializeXml' accepting a first 
argument of 
type 'Ditmer.Everest.Sporgeskema.Skema' could be found (are you missing a using 
directive or an assembly reference?)
C:\Users\mgravell\Desktop\Bug\Protobuf-issue\IntegrationTests.cs(34,32): error 
CS1061: 'string' does not contain a definition for 'FindFirstDifference' and no 
extension method 'FindFirstDifference' accepting a first argument of type 
'string' 
could be found (are you missing a using directive or an assembly reference?)
C:\Users\mgravell\Desktop\Bug\Protobuf-issue\IntegrationTests.cs(37,31): error 
CS1061: 'Ditmer.Everest.Sporgeskema.Skema' does not contain a definition for 
'SerializeProtoBuffer' and no extension method 'SerializeProtoBuffer' accepting 
a 
first argument of type 'Ditmer.Everest.Sporgeskema.Skema' could be found (are 
you 
missing a using directive or an assembly reference?)
C:\Users\mgravell\Desktop\Bug\Protobuf-issue\IntegrationTests.cs(40,11): error 
CS1061: 'Ditmer.Everest.Sporgeskema.Skema' does not contain a definition for 
'DeserializeProtoBuffer' and no extension method 'DeserializeProtoBuffer' 
accepting a 
first argument of type 'Ditmer.Everest.Sporgeskema.Skema' could be found (are 
you 
missing a using directive or an assembly reference?)
C:\Users\mgravell\Desktop\Bug\Protobuf-issue\IntegrationTests.cs(42,35): error 
CS1061: 'Ditmer.Everest.Sporgeskema.Skema' does not contain a definition for 
'SerializeXml' and no extension method 'SerializeXml' accepting a first 
argument of 
type 'Ditmer.Everest.Sporgeskema.Skema' could be found (are you missing a using 
directive or an assembly reference?)
C:\Users\mgravell\Desktop\Bug\Protobuf-issue\IntegrationTests.cs(45,27): error 
CS1061: 'string' does not contain a definition for 'FindFirstDifference' and no 
extension method 'FindFirstDifference' accepting a first argument of type 
'string' 
could be found (are you missing a using directive or an assembly reference?)

Original comment by marc.gravell on 16 Nov 2009 at 8:56

GoogleCodeExporter commented 8 years ago
Sorry, Marc, here's the updated solution...

Original comment by badmot...@gmail.com on 17 Nov 2009 at 10:32

Attachments:

GoogleCodeExporter commented 8 years ago
OK ta; will look later today.

Original comment by marc.gravell on 17 Nov 2009 at 11:05

GoogleCodeExporter commented 8 years ago
It's a fairly complex scenario with both inheritance and custom collection 
types. I'd 
be happy to help you get started debugging. 
Just tell me what you need, I am eager to find a solution.

Original comment by badmot...@gmail.com on 19 Nov 2009 at 1:31

GoogleCodeExporter commented 8 years ago
Sorry, I haven't had chance to look at this yet; I intended looking at this on 
the 
train, but: http://twitter.com/marcgravell/status/5852411890

Will look at this later today - honest!

Original comment by marc.gravell on 19 Nov 2009 at 2:30

GoogleCodeExporter commented 8 years ago
So far, the difference I'm seeing is relating to DateTime; 1994-03-01T00:00:00 
vs 1994-
03-01T00:00:00+00:00; I'm just trying to find where that data is in the model 
(it isn't 
100% clear with an unfamilar model...)

Original comment by marc.gravell on 19 Nov 2009 at 8:56

GoogleCodeExporter commented 8 years ago
Assuming I'm looking at the same bug as you, it seems to come down to 
DateTime.Kind - 
the original returns "unspecified", and protobuf-net *should* return 
"unspecified", but 
seems to be "local" in some case; I'm still investigating why this could be. It 
may 
also relate to the constructor usage; we shall see...

Original comment by marc.gravell on 19 Nov 2009 at 10:01

GoogleCodeExporter commented 8 years ago
Yes, I'm using local dates, hence the +01:00 timezone. I can live with that 
because 
in this current application I only need day accuracy.

My real problem is that, in some cases, Collection<UploadedFileId> is empty. 
Also, 
some of my Nullable<DateTime>s don't get serialized at all. Mostly they do, but 
once 
in a while far down into the graph, they don't. And the weird thing is, the 
mapping 
does not differ. It's the same property on the same class that sometimes work 
and 
sometimes doesn't.

Original comment by badmot...@gmail.com on 20 Nov 2009 at 7:36

GoogleCodeExporter commented 8 years ago
Oddly enough, the datetime issue was "there" last night and not today... very 
odd! I'm 
still looking; re the upload - yes, that is what I saw today; the trick then is 
finding 
the data that is funky ;-p A quick inspector shows me that:
.Sektioner[1].Sporgsmalr[0].Svartype.Svar[0].Sporgsmalr[3].Svartype.Svar[0]
is playing up, so I'll have a look at that... getting there... but yes, some 
odd things 
happening.

Original comment by marc.gravell on 20 Nov 2009 at 7:52