Merge lp://staging/~brian-murray/oops-repository/bucketversion into lp://staging/~ev/oops-repository/whoopsie-daisy
Proposed by
Brian Murray
Status: | Needs review |
---|---|
Proposed branch: | lp://staging/~brian-murray/oops-repository/bucketversion |
Merge into: | lp://staging/~ev/oops-repository/whoopsie-daisy |
Diff against target: |
46 lines (+17/-0) 3 files modified
oopsrepository/oopses.py (+4/-0) oopsrepository/schema.py (+4/-0) oopsrepository/tests/test_oopses.py (+9/-0) |
To merge this branch: | bzr merge lp://staging/~brian-murray/oops-repository/bucketversion |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Evan | Needs Information | ||
Review via email: mp+149180@code.staging.launchpad.net |
Description of the change
This adds the bucketversion cf which uses the custom comparator.
To post a comment you must log in.
Unmerged revisions
- 58. By Brian Murray
-
add and use bucketversion cf which uses a dpkgversiontype custom comparator
Would this still work for your needs if it was a composite type of (DpkgVersionCom parator, UTF8) where the latter part of the tuple represents the Ubuntu release that version is responsible for? The ordering matters here, as we want to sort on the dpkg version primarily.
Getting the first version this issue was ever seen in would still be: cf.get( column_ count=1) -> ('1.0-0ubuntu1', 'Ubuntu 12.04')
bucketversions_
Getting the total count of instances for the first version this issue was ever seen in, regardless of release, would require two operations as far as I can tell [1]: cf.get( column_ count=1) -> ('1.0-0ubuntu1', 'Ubuntu 12.04') cf.get_ range(column_ start=' 1.0-0ubuntu1' , column_ finish= '1.0-0ubuntu2~ ')
bucketversions_
bucketversions_
But if we grabbed the entire row, we could build an accurate table of "package versions with this error", as described in the specification: /wiki.ubuntu. com/ErrorTracke r#Bucket_ page
https:/
And mentioned in the following bug report: /bugs.launchpad .net/errors/ +bug/1078801
https:/
Alternatively we could have another column family responsible for this finer granularity.
1: http:// mail-archives. apache. org/mod_ mbox/cassandra- user/201208. mbox/%<email address hidden>%3E