You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, great job on this and the caching framework. I have a problem however that I need some explanation about. Why is is that non-parse properties are serialized? This doesn't seem right (at least for the purpose of caching subclasses of PFObject). The problem is this, if you register your own sub class of PFObject, and it has some read-only properties (which are usually calculated) these may cause problems.
Assume class A and class B, both subclasses of PFObject. A refers to B, B has a read only property that calculates a value based on a PFObject field. However, when A was loaded, it only loads a pointer to B, and not all of B's fields. When the PFObject+NSCoding tries to encode A, it transitively encodes B, including B's non Parse fields. This means that the readonly property method is called, which tries to read a field that was not loaded and fails with Parse library saying that the field needs to be loaded first.
I worked around this by commenting out the following two lines of PFObject_NSCoding (line 87):
It seems that we need a way to turn off serialization of Non-Parse fields, or indicate a property (especially read-only ones) should not be serialized. I'm happy to work on a solution for this, but first I wanted to fully understand the motivation to start with for serializing non-parse fields. My best guess is that PFObject+NSCoding is designed to be a generic serialization mechanism. In all cases, it doesn't make sense to serialize read-only properties since trying to restore them later could only fail.
Please let me know your thoughts.
The text was updated successfully, but these errors were encountered:
Hi, great job on this and the caching framework. I have a problem however that I need some explanation about. Why is is that non-parse properties are serialized? This doesn't seem right (at least for the purpose of caching subclasses of PFObject). The problem is this, if you register your own sub class of PFObject, and it has some read-only properties (which are usually calculated) these may cause problems.
Assume class A and class B, both subclasses of PFObject. A refers to B, B has a read only property that calculates a value based on a PFObject field. However, when A was loaded, it only loads a pointer to B, and not all of B's fields. When the PFObject+NSCoding tries to encode A, it transitively encodes B, including B's non Parse fields. This means that the readonly property method is called, which tries to read a field that was not loaded and fails with Parse library saying that the field needs to be loaded first.
I worked around this by commenting out the following two lines of PFObject_NSCoding (line 87):
It seems that we need a way to turn off serialization of Non-Parse fields, or indicate a property (especially read-only ones) should not be serialized. I'm happy to work on a solution for this, but first I wanted to fully understand the motivation to start with for serializing non-parse fields. My best guess is that PFObject+NSCoding is designed to be a generic serialization mechanism. In all cases, it doesn't make sense to serialize read-only properties since trying to restore them later could only fail.
Please let me know your thoughts.
The text was updated successfully, but these errors were encountered: