Closed ierceg closed 10 years ago
Hi! Type [] was not designed for that purpose. Currently this is not documented feature and our team working on better implementation that will cover both complex type case and your case. Now it only designed to work with complex objects as subtype, and your change breaks current logic. How it should work: when you specify type of property as [Number] or [String] it should not convert data to {id: ...} and just pass it as is, when untyped property specified ([]), then list will see what was passed and if primitive object passed, then add it as is, without converting to {id: ...}. But at the moment it is not implemented. If you have time to implement this logic without breaking current logic of complex types - go for it. Otherwise, just use JSON type to store array as is.
Thanks for the answer. I suspected that I was screwing something up with my changes but that "id" was bugging the hell out of me (basically I have a code that reads the array, unions it with another array and if the content changed updates it in the db; with "id" being inserted it was happening on every read from the db).
I'll try to fix it proper when I get some time.
Before the fix doing this:
would print this:
After the fix the arrays are correctly assigned and the example above prints out:
Furthermore, storing such an array into the database was working correctly but retrieval of arrays was adding bogus "id" fields and converting values like strings from "123" into objects like { "123", id: 1 }. To make the matters worse this was applied to all the items in arrays.
I didn't find any better solution that to simply skip creating ListItem objects for Arrays. To be honest I suspect that there is a good reason to insert those "id"s but for me it was simply corrupting the data.
Finally, I changed the original commit to work, I think, more cleanly with arrays in lists, reading and setting them in list.items property.