ManyArray with ID-less records

3 views
Skip to first unread message

Dave Porter

unread,
Feb 9, 2014, 11:51:35 AM2/9/14
to sproutc...@googlegroups.com
I think this feature, while awesome, isn't ready yet, and should be disabled by default and rethought.

The core idea that a ManyArray shouldn't dirty its record when ID-less records are added makes a lot of sense and will be tremendously helpful to the order-of-operations challenge that everybody runs into at some point (and I think should actually be extended to all READY_NEW records).

But I think it should go a step further: the new record's placeholder IDs shouldn't show up in the record's underlying data hash at all. As it stands now, a new record is added to a ManyArray, the ManyArray's record's underlying hash ends up looking like this:

{ manyRelationship: [1, 2, "_sc_id_placeholder_8"] }

If that hash makes it back to the server, for example if the record is dirtied and committed for some other reason in the mean time, then the most likely outcome is the server barfing 500s all over itself.

I don't have a complete solution in mind, but I bet it'll involve maintaining new records separately from the list of extant record IDs. I imagine that will make automating "updateNewRecordId" easier, but integrating the two lists live (e.g. for "length" and "objectAt", not to mention "replace") will be a very fiddly little challenge. Thoughts? If that's the correct approach then it shouldn't be challenging, it should just be a matter of going heads-down and cranking out the fiddly code.

In the mean time, is it alright if I disable supportsNewRecords by default (and comment out the failing unit tests)?

Dave

Dave Porter

unread,
Feb 9, 2014, 1:07:26 PM2/9/14
to sproutc...@googlegroups.com
See /team/dcporter/many-new for my interim fix to this situation. (I've also implemented a global "warn" method for unit testing, which seems like an obvious missing piece to me; if it shouldn't exist for some reason then please let me know.) I'll merge these in tomorrow if there's no objection.
Reply all
Reply to author
Forward
0 new messages