-
Notifications
You must be signed in to change notification settings - Fork 106
Order items by date rather than id #115
Comments
K, found the solution, I'll see if i can implement the stuff ASAP over the weekend (since this also affects the API). I want to push back the beta release to implement this cc @cosenal PS: API draft has already been updated |
The problem arises from articles which are added and have a pubdate which does not comply with the date added. You wouldnt get to see those articles at the top but rather at the bottom. So basically the ordering right now is not based on pubdate but based on how new the entry is which is the proper way to do it imo |
Basically its best to not trust pubdate input at all since theres so much fked up stuff out there. It may still interest you when the author thought the article should be published |
If an email comes in with a "bad" sent date then either Thunderbird makes an invalid interpretation of invalid data (e.g. 15/12/13 is 15th Dec last year in UK, but 13th Dec next year in ISO and invalid in US) and it lands at a best-guess place in your timeline (which is all that can be expected), or it has no date at all and it treats it as the start of the Epoch (which is fair enough, if you're going to ignore the standards, but not ideal), or "bad" just means "sender clock was out by days/weeks/months" and it appears where it is supposed to - chronologically at the point it was sent. |
implemented |
Ok, will probably revert this and go back to ordering by id. The problem is the following:
If you dont autopage by offset:
|
basically i need something like: SELECT * FROM items
WHERE pubdate < ?
SKIP TO id = ? IF FIRST ROWS SAME pubdate which works at least on postgres and mysql |
Closing this because there is no solution |
Maybe you can do it in the template part (with angular in JS) ? In templates/part.items.php, something like this :
I use this modification in my ownCloud at the moment and it works great. |
Nope, autopaging will insert the elements in the wrong order then since ordering is defined by id on the server |
So items will be inserted before your current point and will be marked as read automatically |
This will be harder to implement and will take longer, so next release ;)
Each item has a pubDate which we get as unix timestamp. The problem comes with autopaging. The current algorithm is basically the following:
A timestamp can occur multiple times. If we use the pubdate for querying the following algorithm would be imaginable:
Now what if all items have the same pubdate and there are 400 of them? the algorithm wouldnt load items at all. If you use <= it will load 400 items at once and that kinda breaks efficient autopaging.
Another problem would occur if there are newly added items which have a lower pubdate than on the client. It may even skip items.
The text was updated successfully, but these errors were encountered: