I have read other posts on stack overflow on the issue but my question is a little different..
When storing an object in the Session does PHP save the Complete Object Graph in the session?
I am having problems accessing some of the properties of the Object AFTER it is read from the Session.
The object i am storing has complex type properties with some of them being objects of classes that inherit from other classes, so serializing the object before storing it in the session might be a little "expensive".
What am i missing with Objects and their storage in the Session. Are there limits?
Thank you.
Complex object graphs are serialized fine. Even cyclic references can be serialized. You can't serialize resources though, and certain built-in object types. Generally speaking, serialization is a very expensive operation. You should not rely on it as a shared memory strategy.
Related
An application uses several type of data coded as objects. These objects require to be persistent, and the storage back-end may change (file system, sqlite, nedb are likely options).
What are the best way to design the related code to minimize the hassle to change storage ? A specific Store object to which I would pass my objects ? Have my objects inherit from on that does the storage ? Should my object "self-store" or not ?
For information, the practical case is for a local webapp using node-webkit (javascript) but the answer should probably not be language dependent, as long as it is object oriented.
Whenever you have a functionality that may change, abstract it by introducing an interface, and provide an implementation. In your specific example, you can define an interface IRepository, which would have create/read/update/delete methods for manipulating your objects. Then, you can provide implementations that work with specific storage. In your unit tests, for example, you may use a memory-based implementation that does not even deal with files/DBs/etc, but keeps data in lists.
I'm curious what the advantages of encoding objects in objective c with NSCoding and writing them to disk may be over simply writing a persistence object to disk. Is there a performance increase in terms of I/O or disk space usage?
Well, most NSCoding implementations will handle object graphs correctly; i.e. if you code a member object that's already been coded to the coder, it won't code it again. Decoding will restore the object graph correctly (so the decoded target object has multiple inbound references). You also get all the built in helper coding functions (for primitive types, and objects).
Other than that, NSCoders are just persistence object generators, so you end up doing similar work, only without the annoyances and common cases handled by Apple. What persistence generator could you write that wouldn't duplicate tonnes of NSCoder functionality?
I have complex objects with collection fields which needed to be stored to Hadoop. I don't want to go through whole object tree and explicitly store each field. So I just think about serialization of complex fields and store it as one big piece. And than desirialize it when reading object. So what is the best way to do it? I though about using some kind serilization for that but I hope that Hadoop has means to handle this situation.
Sample object's class to store:
class ComplexClass {
<simple fields>
List<AnotherComplexClassWithCollectionFields> collection;
}
HBase only deals with byte arrays, so you can serialize your object in any way you see fit.
The standard Hadoop way of serializing objects is to implement the org.apache.hadoop.io.Writable interface. Then you can serialize your object into a byte array using org.apache.hadoop.io.WritableUtils.toByteArray(Writable ... writable).
Also, there are other serialization frameworks that people in the Hadoop community use, like Avro, Protocol Buffers, and Thrift. All have their specific use cases, so do your research. If you're doing something simple, implementing Hadoop's Writable should be good enough.
I have a class that is marked as serializable and have no problem storing it in the Session but when I attempt to save it in the ViewState I get:
Sys.WebForms.PageRequestManagerServerErrorException: Error serializing value
The reason is that view state serialization is done by the LosFormatter class while session serialization is done by the BinaryFormatter class. The two are subtly different and one of these subtle differences is probably causing your problem.
Take a look at this article and the documentation for LosFormatter to see if you can find some clues about what is causing your problem.
Well it also depends what kind of session do you use. If it's in-proc, then serialization doesn't take place at all. Your objects get stored into memory.
how does Serialization of objects works? How object got deserialized and a instance is created from serialized date without a call to any constructor?
I've kept this answer language agnostic since a language wasn't given.
When the object is serialized, all the require information to rebuild it is encoded in way which can be retrieved. This typically includes the type of the object, as well as the value of all the instance variables.
When the object is deserialized, an area in memory of the correct size is allocated and is populated using the serialized information such that the new object is identical to the serialized one.
The running program can then refer to this new object in memory without having to actually call the constructor.
There are lots of little details which this doesn't explain, but this is the general idea of serialization/deserialization.
Are you talking about Java? If so, serialization is an extralingual object creation mechanism. It's a backdoor that uses native code to create the object without calling any constructors. Therefore, when designing a class for serializability, you need to make sure that a class created through deserialization maintains the same invariants (key fields being initialized) as you would through the constructor path. A third way to create objects in Java is through cloning, and similar issues apply.
Cloning and serialization don't interact well with the use of final fields if you need to set the value of that field to something different than what is returned by clone or the deserialization process.
Josh Bloch's "Effective Java" has some chapters that explain these issues in more depth.
(this answer may apply to other languages too, but I've only used serialization in Java)
Regarding .NET: this isn't a definitive or textbook answer, and I might be all-out wrong...
.NET Serialization needs to be seperated out into Binary vs. others (XML or an XML derivitave typically). Binary serialization is mostly a black-box to me, but it allows the object to be serialized and restored in their current state. XML serialization typically only serialized the public fields/properties of an object, unless overriden by adding a custom ISerializable implementation.
In the case of XML serialization I believe .NET uses Reflection to determine which fields and properties get converted to their equivalent Elements. Adding an [XMLSerializable] attribute will implement a default behavior which can be adjusted by applying other attributes at the field level (such as [XMLAttribute]).
The metadata (which Reflection depends on) stores all the object members as well as their attributes and addresses, which allows the serializer to determine how it should build the output.