That’s fine. I can always send you the actual application I’m building if you think that would help
As a test, I modified line 84 to this:
if( objProp != null && (!ObjectUtil.isSimple( objProp ) || objProp is Array) && (!objInfo.metadata[item.localName].hasOwnProperty(“InverseJoinColumn”)))
And marked the recursive property with [InverseJoinColumn] (not sure what that metadata is, but it came up in IntelliJ’s code completion so I used it) and everything saved just fine!
In that test, I was just saving the Set object which contains the inverse relationship to the WorkoutItem. If I had changes in the WorkoutItem, I’m assuming those wouldn’t get saved, and I’d probably have to save the WorkoutItem separately, which is fine by me.
I did find another issue though. The Set object also has a array of Resistance objects property called ‘resistances’. After the Set is ran through that Utils class it causes any of the Resistance objects in that array to be converted to generic objects. I think I’ve witnessed that occurring in the past when saving the WorkoutItem.sets[] (each Set object being converted to generic objects), so the problem might be specific to arrays. Watching the debugger, the conversion happens around line 47. Since those array elements are references, the conversion is applied in my app causing “Cannot convert [type] to Object” errors.
I verified the other issue, it does seem to only occur with Arrays. If I save an individual ‘Set’ object, the result is a Set.resistances[] populated with generic objects that can’t be converted to Resistance objects.
If I save an individual WorkoutItem object, the result is a WorkoutItem.sets[] populated with generic objects that can’t be converted to Set objects.
I’m curious as to if the reason it doesn’t happen with non-array property values is because they are being assigned to a typed property which .as is doing some sort of implicit conversion, whereas with arrays, the indices aren’t being assigned to a type.
The result object in the save() responder looks fine, but I can’t use it because I get the conversion errors before the responder returns. I think that is because of the use of the DataGrid… the moment the Utils class sets those generic objects on the Arrays, that causes the Datagrid to refresh those rows, which causes my code to loop the Array elements as specific types (throwing the conversion error).
I was going to experiment with a couple things, like seeing if I can prevent the grid from listening for dataprovider changes during a save operation, or maybe sending the save operation copies of my model objects instead of references.
Update… if I pass the save method a copy of the objects, that seems to work. I’m not longer receiving any errors saving a WorkoutItem object or saving a Set object. I’m using this in my base Entity class (the base class for all my backendless objects:
return Backendless.Data.of(classReference).save(ObjectUtil.copy(this), responder);
It might be a good idea for the backendless client library to be doing the copy operation instead… if it doesn’t cause any other problems, which I can’t think of any it would.
I tested out just making copies of the array properties in the library, instead of making a copy of the entire object graph before saving, in case that object graph is really big. Everything still seems to work fine. I changed line 45 to look like this:
else if( obj is Array )
{
var objCopy:Object = ObjectUtil.copy(obj);
for( var prop:* in objCopy )
objCopy[ prop ] = prepareArgForSend( objCopy[ prop ] );
return objCopy;
}
Hi Devin,
I removed all the Transient attributes and reproduced the problem. It has been fixed and I committed changes to github. The entire hierarchy with recursive references can be serialized without any problems. There is also an updated library in the downloads section on our website.
Regards,
Mark
Tried it out and everything seems to be working fine. Thanks for working with me on that.