SQL: implement defered insertion of new articles (better date sorting)

[Alkarex]

Following a discussion on the matter, and after considering various approaches, I plan to implement #344 (comment)
Within each cron or manual refreshing, articles will be sorted by their declared date in a temporary table before being committed to the main table with their definitive ID.

[Pazns]

Dans la question #344 , il est évoqué ceci :

Changer l'affichage des articles pour les trier par date déclarée. Il faudrait alors sûrement corriger la date déclarée pour un certains nombre de problèmes (en particulier les dates fortement dans le futur), ce qui ferait perdre l'information originelle. Cela compliquerait un tout petit peu la procédure de "marquer tout comme lu". Il faudrait aussi mettre un index SQL sur e.date.

Pourquoi une date dans le futur serait un problème ?
Être situé dans le futur ne rend pas une date incorrecte. Pareil pour une publication avec une date fortement dans le passé, même si cette date est un timestamp 0.
On peut dégager un sens pour une date dans le futur, ou fortement dans le passé, justement pour des questions d'ordre.
Un article publié « demain » resterait alors sur le dessus de la file tant qu'on ne serait pas « demain », même si d'autres flux publient, dans l'absolu, d'ici là. Et un article avec un timestamp 0, ou une date encore au-delà avec un formalisme différent (je pense à ISO8601), serait au plus bas de la file.
C'est un comportement assez étrange mais pourtant qui ne contrevient pas au comportement attendu d'un flux RSS.

Ce n'est pas le rôle d'un agrégateur de savoir si une date annoncée est erronée ou illogique. Il ne peut, en fait, pas le savoir sans faire, un jour, de contresens ou de supposition hasardeuse.

La question de pouvoir corriger des cas particuliers manifestement faux est très pertinente, cependant il est dommageable de restreindre le champ d'action de tous les flux reçus juste parce qu'une fraction fait n'importe quoi avec le standard.

[Pazns]

ping @Alkarex
( Au cas où vous n'auriez pas vu mon message. Excusez-moi dans le cas contraire. )

[Alkarex]

@Pazns Voir #344 les dates déclarées (ou pas) par les flux sont trop souvent erronées pour être utilisées. Pour être plus concret avec les dates 1 an dans le futur, si 100 articles sont dans le futur, il vous sera difficile de trouver ce qui est actuel, et vous verrez toujours les mêmes articles en tête. Ce n'est qu'un problème parmi beaucoup d'autres.

Si vous tenez absolument au classement par date déclarée, vous pouvez changer le code, voir #742 (comment) , mais cela génèrera plus que probablement divers types de problèmes.

Le classement actuel marche déjà bien grâce au rafraîchissement par cron et PubSubHubbub (push), et l'approche proposée ci-dessus devrait finir le travail. À noter que d'autres services comme feu-Google Reader utilisent une approche similaire à ce que fait FreshRSS.

[Pazns]

Est-il possible de réindexer les articles pour respecter leur ordre chronologique en suivant leurs dates de publication déclarées, en admettant qu'elles soient « acceptables » ?

[Alkarex]

@Pazns Oui, il faut faire une requête SQL UPDATE qui trie sur le champ date, et génère un ID unique basé sur cette date (à la fois pour date et id, c'est le système de date Unix, avec date en secondes et id en microsecondes).

[Pazns]

En effet, cela a bien fonctionné, avec un update de l'id tel que "entry.id=date*1000000+entry.ROWID", sous SQLite. Ma base ayant moins de 999,999 articles, l'unicité est garantie.

Les problèmes que vous souleviez dans la question #344 ne sont-ils pas causés par le fait que vous voulez répondre à une question à la fois d'unicité et d'ordre avec un seul champ SQL ?
L'ajout d'un champ "date" stabilisé, intermédiaire, semble obligatoire.
À la réception, si la date de publication déclarée est cohérente (par exemple, - 5 ans et + 1 semaine maximum), elle serait copiée dans un champ de date réelle telle quelle, sinon la date de réception est utilisée.
L'identifiant unique serait alors autre chose, complétement déconnecté d'une notion d'ordre.

Le surcoût en donnée (un ajout d'un champ par enregistrement) ne semble pas horrible, même pour des dizaines de milliers d'articles.
Il faudrait voir surtout si les performances suivent au niveau de l'indexation. Une perte de performance se fait-elle vraiment ressentir sur des bases inférieures à plusieurs centaines de milliers d'articles ?

[Pazns]

Un avis sur la question, @Alkarex ?

[Alkarex]

Ce que vous proposez est similaire à ce que FreshRSS utilisait au début, et qui marchait mal (champ e.id pour l'unicité, et e.date pour la date et tri) à la fois au niveau logique et au niveau performances.
Pour que cela fonctionne correctement dans les différents cas d'utilisation (y compris par exemple lorsque de nouveaux articles arrivent pendant que l'utilisateur est en train d'en lire et/ou s’apprête à marquer la section comme lue, pour la pagination, ou encore pour la synchronisation avec l'application mobile par API), il faut un champ (actuellement e.id) qui offre des garanties, entre particulier être monotone croissant. C'est-à-dire qu'il faut qu'un nouvel article soit ajouté avec un e.id strictement plus grand que le plus grand des e.id existants (il serait compliqué de l'insérer au milieu d'articles existants sans que cela génère différents problèmes pour la synchronisation API, la pagination, marquer comme lu).

[Pazns]

Et on ne peut pas mettre en place un incrémenteur automatique pour s'assurer de toujours augmenter l'id ?

SQLite peut réutiliser le ROWID, donc il n'est pas fiable sur ce point, cependant il existe d'autres possibilités : http://www.sqlite.org/faq.html#q1
De même avec MySQL.

[Alkarex]

L'incrémentation automatique n'est pas un problème :-)

[Pazns]

J'avoue avoir du mal à saisir le problème, dans ce cas.

[Alkarex]

Il n'y a pas de problème : FreshRSS marche actuellement relativement bien (surtout en utilisant PubSubHubbub et un cron automatique régulier), et une fois implémentée l'approche présentée plus haut, cela devrait encore mieux convenir à ceux qui ne sont pas entièrement satisfaits du classement actuel des articles (je pense que ça devrait vous aller aussi). Ce qui serait un problème serait de ré-introduire un classement qui casserait la garantie de monotonie.

[k0ral]

En tant qu'utilisateur de freshrss, je suis très dérangé par ce choix de tri par date d'insertion plutôt que par date de publication déclarée. C'est d'ailleurs la 1è fois que je tombe sur un aggrégateur de flux qui a fait ce choix-ci.

Ne connaissant pas le fonctionnement interne de freshrss, je ne peux décemment argumenter sur le terrain technique, toutefois un parcours rapide de vos discussions suggère que ce choix a été fait principalement car (1) cela simplifie l'implémentation de la concurrence/synchronisation, et (2) cela évite des soucis avec les dates mal voire non renseignées (corrigez-moi si je me trompe), ce qui me laisse sceptique.

Toute considération technique mise à part, il est à mon sens important que l'implémentation de fonctions avancées (telles que (1)), et les palliations à un standard défectueux (telles que (2)) ne détériorent pas l'expérience utilisateur sur les fonctions de base (telles que le tri par date).

[Alkarex]

@k0ral Le tri devrait être mieux lorsque j'aurai implémenté le ticket actuel. Sans revenir sur ce qui a déjà été abondamment discuté et expliqué précédemment, voici quelques points supplémentaires suite à votre commentaire.

Le tri actuel de FreshRSS est loin d'être un cas isolé. Google Reader faisait pareil. Voici quelques captures d'écran de feu Google Reader, où on peut voir que les dates ne sont pas strictement dans l'ordre :

• https://reprog.wordpress.com/2011/11/01/face-it-google-everyone-hates-the-new-google-reader/
• http://451heat.com/2013/03/15/samsung-galaxy-s4-debut-google-reader-gone-pinterest-as-an-analytics-tool-social-media-reactions-to-wes-welker/
• C'est encore plus visite sur un client de bureau pour Google Reader http://screenshots.en.sftcdn.net/en/scrn/3344000/3344212/desktop-google-reader-01-700x525.png

TT-RSS semble avoir copié le mécanisme de Google Reader (je n'ai pas vérifié) https://tt-rss.org/forum/viewtopic.php?t=1545

Et The Old Reader aussi, comme visible sur http://themefortress.com/assets/theoldreader.jpg

Feedly (au moins la dernière fois que j'ai regardé il y a plus d'un an) a une approche similaire. De même que nombre d'autres aggrégateurs qui ne montrent pas la date déclarée à l'utilisateur, mais seulement le temps depuis la réception (Digg, AOL Reader...) http://gizmodo.com/10-google-reader-alternatives-that-will-ease-your-rss-p-5990540

En résumé, tous les plus gros agrégateurs utilisent la date de découverte.

Ne vous méprenez pas : l'expérience utilisateur serait dégradée en utilisant un tri naïf par date déclarée, même pour des fonctions de base, non-avancées, telles le défilement et le marquer comme lu.
Si vous voulez tout de même essayer, vous pouvez changer quelques ORDER BY xxx.id par ORDER BY xxx.date dans https://github.com/FreshRSS/FreshRSS/blob/beta/app/Models/EntryDAO.php mais attendez-vous à des bugs...

Ceci dit, je suis tout de même curieux de savoir dans quel cas vous avez une différence entre l'ordre de découverte et l'ordre de date déclarée, et que cela est un problème important.

[planetahuevo]

@Alkarex
May I suggest that when the new feeds are sorted on the discovery phase, use for sorting this method:

• First sort by day of discovery (not hours and seconds, just the day).
• After that sort by post date (which could be wrong, but that will order the different posts and mix the sources together).
• insert into database in that order.

This way the sources will be mixed when the discovery is done which will also help to servers like mine that sync every24 hours.

Not sure how difficult will this be.
What do you think?

[Alkarex]

The approach suggested in the current issue will help for situations like yours when updates are done infrequently, and will indeed sort by declared date before inserting in database.

[Pazns]

In my case, FreshRSS updates 4 or 5 times a day, and I still get posts roughly packed together by source in the list. It's a bit strange to see dates going back in time, then forward...

[planetahuevo]

@Pazns Do you think my suggestion will work?
Maybe we could use day and hour but not seconds to sort by discovery.

[Alkarex]

@Pazns Yes, that is the current behaviour, as explained, for feeds that do not have PubSubHubbub

[planetahuevo]

@Alkarex Sorry but for me is still not clear what is the current behaviour and what is the change propossed. Late to the conversation I think...

[Pazns]

@Alkarex : Ah, I didn't know that ! Still strange to see in action, but okay.

[Alkarex]

TLDR summary:

• Current situation: Feeds are updated one at a time, with articles immediately inserted in database, and articles are then sorted like the database order (discovery date);
• Proposed feature: Feeds are updated as a group, then new articles are sorted by declared date, then new articles are inserted in database, and articles are then sorted like the database order;

[planetahuevo]

@Alkarex thank you very much!
Then we are saying the same thing. 👍
You could divide feeds into categories to update too, so you do not need to update all the feeds at the same time.
But any of those approach will work.

[Alkarex]

Draft of implementation available for testing in #1470