It's best to do that, because worker payload is usually outdated. If
there is no info on repo yet, it's worth to add it, but if it already
exists, we will most likely end up with inconsistent situation.
It's best to do that, because worker payload is usually outdated. If
there is no info on repo yet, it's worth to add it, but if it already
exists, we will most likely end up with inconsistent situation.
While testing in the wild I spotted a few problems with it:
* it didn't work for camel case names.
* it was sometimes setting loaded data too late - it needed to use find
and then save data on the record. Instead it should save data in
special array saved on store, indexed by clientId
* there is already method to get attributes in ember-data, it just
doesn't work with Travis.Foo.get('attributes'), it needs
Ember.get(Travis.Foo, 'attributes') - it makes implementation much
shorter
If we have 2 jobs within 1 build, with such config values:
{ rvm: 'jruby-head', jdk: 'oraclejdk7' }
{ rvm: '1.9.3', jdk: null }
We should return jdk in configValues for second build, even if it's not
present. Otherwise table rows may be missing.
(closes#28)
If we keep it only on states lower than root and afterSignIn is sent
when app is still in root.loading (which is often the case as we need to
wait for repository deserialization), it will try to find afterSignIn on
root.
In order to minimize ajax requests, I implemented isComplete property,
which can be used to check if record is fetched from the API or if it
was just partially loaded (for example by pusher event). This is nice in
terms of requests reduction, but caries risk of showing incomplete data.
This commit fixes this situation by saving which attributes were
provided on "incomplete" load and triggering refresh when any unknown
attribute is tried to be fetched.
The implementation is really simple and will probably need refactoring,
but I would like to test it in the wild before putting much more time
into it.
