ManyArray (toMany attributes) could use a status

[Dave]

The use case is when you're holding up a state transition until all the records in a toMany attribute are done loading or updating. Currently I'm doing a bunch of addObserver/removeObserver loops on the individual records.

This is barely a step above pseudocode, but here's a possible implementation:

  status: function() {

    console.log('hi!');

    var ret = SC.Record.READY_CLEAN;

    (this.get('content') || []).forEach(function(rec) {

      // Build a status hierarchy. (E.g. ready_clean is best, busy is middle, error is worst.) If rec.get('content') beats current ret, replace ret.

    });

    return ret;

  }.property('@each.status').cacheable()

Thoughts on the need for this, or the implementation?

Cheers,

Dave

[Topher Fangio]

I have used a different approach for similar issues at the request level that works very well for me.

Basically, I overrode SC.Request.didReceive and I look at the records that came in and did something like the following:

    didReceive: function(request, response) {

      var type = response.getPath('body.recordType');

      if (!SC.none(type)) {

        MyApp.dataEventsController.incrementProperty(type + '_updates');

      }

    }

Now, I observe this one property whenever I care about that type of record (say "Blog_updates" or "BlogComment_updates") and can check the status or many array then. This involves far less observers firing and thus, a much faster app.

I realize this doesn't apply to every situation, but in general, I have found that working at the lower level of the SC.Request object gives me far less headaches.

So, I guess this is all to say: could we do this at a lower level instead of using @each.status? When you start working with a lot of records, that means a lot of observers firing and could introduce some performance problems.

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

--
You received this message because you are subscribed to the Google Groups "SproutCore Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sproutcore-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dave Porter]

Absolutely, doing it at a lower level would be preferable. (SC.Request is TOO low though, at least for a generalized solution.) Building something into the dataSourceDidFoo methods seems to make the most sense to me – the store could keep track of ManyArrays and proactively tweak the status of affected ones when they change. I believe that's how SC.RecordArray does it?

[Topher Fangio]

That definitely sounds like a good and welcome change to me; although I'm afraid I don't know the data sources well enough to say exactly where it should go :-)

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Maurits Lamers]

What about using SC.RecordArray#status? Or "upgrade" ManyArray to be a RecordArray (as from your question it sounds like it isn't)

Cheers

Maurits

[Dave Porter]

Correct that ManyArrays are entirely different than RecordArrays. Some unmeasured performance bogeyman is the best argument I can think of for not replacing ManyArrays wholesale with a RecordArray subclass that creates its own query, but maybe there's a better reason?