0

why we can't Serialize objects into Random Access file ? and on the other hand we can serialize objects into sequential access file ?

""C# does not provide a means to obtain an object’s size at runtime. This means that, if we serialize the class, we cannot guarantee a fixed-length record size "" (from the book that i read in).

so we cannot read the the random access file because we don't know every object size in the file so how we could do seeking ??????

Sherif
  • 1,249
  • 4
  • 15
  • 38
  • 3
    What do you mean by "Random Access file." You can serialize objects to any class that inherits from `System.Stream` – Mehrdad Afshari Aug 23 '09 at 14:28
  • Could you include example code that does not work? – Richard Aug 23 '09 at 14:52
  • check the question after edit it. – Sherif Aug 23 '09 at 15:08
  • 3
    "so how we could do seeking?" You wouldn't seek. You'd just start from the beginning of file and deserialize objects sequentially, one after another. If you need to pick up some specific object to deserialize, at the time of serialization, you'd build an index somewhere to record the offsets. – Mehrdad Afshari Aug 23 '09 at 15:18

2 Answers2

2

Any object marked with the SerializableAttribute attribute can be serialized (in most scenarios). The result from serialization is always directed to a stream, which may very well be a file output stream.

Are you asking why an object graph cannot be deserialized partially? .NET serialization only [de]serializes complete object graphs. Otherwise you'll have to turn to other serialization formatters, or write your own.

For direct random access to a file, you must open the file with a stream that supports seeking.

EDIT:

Seeking in the resulting stream from a serialization has no practical purpose - only the serialiation formatter knows what's in there anyway and should always be fed the very start of the stream.

For persisting the data into other structures; do it in a two-stage process: First, target the serialization bytes to a [i.e. memory-backed] stream that you can read the size from afterwards, then write the data to the actual backing store, using said knowledge of size.

You can't predict the size of a serialized object, because the serialized representation might differ a lot from the runtime representation.

It it still possible to achieve exact control over output size, if you use only primitive types, and you write using a BinaryWriter - but that is not serialization per-se.

Cecil Has a Name
  • 4,962
  • 1
  • 29
  • 31
  • ""C# does not provide a means to obtain an object’s size at runtime. This means that, if we serialize the class, we cannot guarantee a fixed-length record size "" (from the book that i read in). so we cannot read the the random access file because we don't know every object size in the file so how we could do seeking ?????? – Sherif Aug 23 '09 at 15:07
  • You can always serialize to a stream from which you can decipher the number of written bytes. MemoryStream is a good candidate for this. After that, the data can be persisted by other means, prefixed or indexed with length. – Cecil Has a Name Aug 23 '09 at 15:37
0

The default binary serialization in .NET serializes a whole object graph, which, by its nature of being a graph, doesn't have a constant size, which means each serialization object (record) won't have a constant size, preventing random access.

To be able to randomly access any record in a file, write your own implementation of the binary serialization of your class, or use a database. If you need a simple, no-install single-threaded database engine, have a look at SQL Server Compact.

Allon Guralnek
  • 15,813
  • 6
  • 60
  • 93
  • The graph's size in its serialized state is very constant ;) – Cecil Has a Name Aug 23 '09 at 15:49
  • True, but it has no relevance to the question or to my answer. The serialized size of an object cannot be predicted at compile time since the entire object graph needs to be serialized at run time. The size of the graph at run time cannot be guaranteed. – Allon Guralnek Aug 24 '09 at 13:31