Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

store.all() is not treated as a filteredRecordArray anymore #3167

Merged
merged 1 commit into from
Jun 6, 2015
Merged

store.all() is not treated as a filteredRecordArray anymore #3167

merged 1 commit into from
Jun 6, 2015

Conversation

pangratz
Copy link
Member

@pangratz pangratz commented Jun 2, 2015

This addresses #2542


I haven't squashed the commits so the changes are more comprehensible. If this is accepted, I will squash em all!


if (this.liveRecordArrays.has(typeClass)) {
var liveRecordArray = this.liveRecordArrays.get(typeClass);
if (!liveRecordArray.isDestroyed && !liveRecordArray.isDestroying) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The check for the record array not being destroyed is needed as otherwise this test fails.

I am not satisfied about this check; how should this be tackled? Check if the RecordArray which is about to be destroyed is a liveRecordArray and if so, remove it from the map?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems like previously it was handled by unregisterFilteredRecordArray, called when in the recordArray's destroy method.
Maybe this could be rename as unregisterRecordArray which could handle both filtered/live record arrays ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good 👍

return this.liveRecordArrays.get(typeClass);
},

/**
Create a `DS.RecordArray` for a type and register it for updates.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment needs to be updated since the register it for updates is no more valid ...

@pangratz
Copy link
Member Author

pangratz commented Jun 3, 2015

I refactored the whole thing a little more and kept the commits so the changes are more comprehensible.

if (!recordArrays.has(array)) {
array.addRecord(record);
recordArrays.add(array);
updateLiveRecordArray: function(array, modelName) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't really update anymore, just initially populates it, so a different name/location might be better

@igorT
Copy link
Member

igorT commented Jun 6, 2015

Can you squash please

var typeClass = array.type;

// unregister filtered records arrays
var recordArrays = this.filteredRecordArrays.get(typeClass);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like we could just know which one it is, and don't need to try both?

@igorT
Copy link
Member

igorT commented Jun 6, 2015

Thanks @pangratz !
Looks good after that one comment and squashing

This refactors the handling of the record array returned by
`store.all()`. Previously it has been treated as a FilteredRecordArray
without a filter function which resulted in awkward code paths. Now
there is a list of liveRecordArrays which contains the RecordArrays
which hold all records for a type.
@fivetanley
Copy link
Member

This looks like it makes it so if you call store.all('post') more than once, you always get the same record array back?

@fivetanley
Copy link
Member

Looks like it. 👍

fivetanley added a commit that referenced this pull request Jun 6, 2015
store.all() is not treated as a filteredRecordArray anymore
@fivetanley fivetanley merged commit 6a4b20c into emberjs:master Jun 6, 2015
@igorT
Copy link
Member

igorT commented Jun 6, 2015

@fivetanley that was the case before as well,this just refactors the code

@pangratz pangratz deleted the fix_2542 branch June 7, 2015 14:40
@sly7-7
Copy link
Contributor

sly7-7 commented Jun 8, 2015

@pangratz Great Work !! Also next time instead of adresses, could you use fixesor closes the referencing issue ?

@pangratz
Copy link
Member Author

pangratz commented Jun 8, 2015

@pangratz Great Work !! Also next time instead of adresses, could you use fixesor closes the referencing issue ?

@sly7-7 I used to do this in my commit messages but I started to refrain from this since otherwise the referenced issue is cluttered with @pangratz referenced this pull request in commit xxx, every time I do a rebase and (re)push to GitHub.

I should get into the habit of adding the closes #xxx once the PR is ready to be merged ...

@sly7-7
Copy link
Contributor

sly7-7 commented Jun 8, 2015

I should get into the habit of adding the closes #xxx once the PR is ready to be merged ...
👍
For me adding the closesthing just after my first commit/push, but in the comment part does the trick

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants