They're semantically two different things.
Readability
Don't treat filters as specific cases
Make it possible to query kns entries by their unique id
Details
Details
- Reviewers
mart leinir - Group Reviewers
Frameworks - Commits
- R304:4d5a820cf7ea: Separate sort roles and filters
Diff Detail
Diff Detail
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage
Comment Actions
to me looks good, is probably better to wait the merge by dan?
| src/core/provider_p.h | ||
|---|---|---|
| 63 ↗ | (On Diff #7838) | EntryId? |
Comment Actions
It would make fine sense to merge this in already (i'll merge it into the branch), as this is, of course, fairly important to get in, and there are things in my branch which may need some further discussions before a final merge (though i hope it's more a case of "woop, do the thing!" ;) ). So... thumbs up from here, all looks fine to me :)
| src/core/provider_p.h | ||
|---|---|---|
| 63 ↗ | (On Diff #7838) | hmm... had a quick think there, and there's a small semantic difference: A filter on EntryID would potentially (in my head at least) filter on whatever you handed it, so filtering by EntryID "123" would find both "123" and "1234", whereas something filtering by ExactEntryID "123" would find only "123"... but it /is/ a very small difference... |