added new BUG
This commit is contained in:
13
BUGs
13
BUGs
@@ -1,4 +1,15 @@
|
|||||||
### Next: 139
|
### Next: 140
|
||||||
|
BUG-139: since AI:mich not %AI:mich% ? going next a few times, ends say 4 pages of 50 into 4000 matches (entries from DB < 50)... Either search is no longer returning all those matches, or the stats page is wildly wrong?
|
||||||
|
- confirmed this is when person has 2 or more refimgs:
|
||||||
|
- on page "2", we get 49 pulled back in the ORM instead of the 50 expected -- b/c I use that to indicate we must be at the end of the list if not 50 found
|
||||||
|
-- really, need to fix once and for all the eids / re-running query.
|
||||||
|
do GetEntries as we do now, once done however, get all entry ids. Stick those into the DB with a unique query-id and datestamp
|
||||||
|
new func to get all details needed for entries in an eid list (of 1-page) - show this page of entries
|
||||||
|
use current, full eidlist and to work our start/end of list (next/prev), disabling.
|
||||||
|
then client can keep current page of data, if you hit next/prev, use DB unique query id / full list and page of eids, and give full data for new page of entries
|
||||||
|
Implications though, are if a search is invalidated (maybe delete / move a photo), need to remove them from the list on the DB too OR let user know/decide to fix/wait.
|
||||||
|
|
||||||
|
|
||||||
BUG-100: I managed to get 2 photos matching mich in the NOT_WORKING photo (probably dif refimgs but same p.tag?)
|
BUG-100: I managed to get 2 photos matching mich in the NOT_WORKING photo (probably dif refimgs but same p.tag?)
|
||||||
= /photos/2012/20120414-damien/IMG_8467.JPG
|
= /photos/2012/20120414-damien/IMG_8467.JPG
|
||||||
BUG-106: cant add trudy /pat? as refimgs via FaceDBox
|
BUG-106: cant add trudy /pat? as refimgs via FaceDBox
|
||||||
|
|||||||
Reference in New Issue
Block a user