Tu peux aussi exposer le fichier data/backend.tsv directement et laisser ton serveur web gérer le caching.
Je compte exposer directement le fichier. Je ne comprends pas à quel caching tu fais allusion...
Si je fais un GET sur l’url sans spécifier If-Modified-Since dans l’entête (ou utiliser un ETag) le serveur doit me renvoyer le contenu, que celui-ci ait changé ou pas... et je ne peux pas trop envoyer moi-même cette entête car je n’ai pas de Last-Modified répondu par le serveur (je sais pas trop quelle date mettre...).
Je fais donc un HEAD afin d’avoir juste les entêtes pour savoir si je dois faire un GET pour avoir le contenu ou bien ce n’est pas la peine (dans ce cas je prends mon cache local).
Mais bon. J’ai l’impression que je me prends la tête pour rien et que ça aurait du sens de procéder ainsi si le contenu faisait 4km de long... mais là, limite, je ferais peut-être mieux de récupérer le contenu à chaque fois...
Le post étant récupéré depuis un backend, pourquoi chercher une corrélation tordu? Un post vient de dlfp parce que tu l'as trouvé dans le backend de dlfp.
J’ai besoin d’une clé primaire pour mes posts, tous bouchots confondus. Pourquoi ? Parce que je pourrais très bien checker deux fois le même backend, pour une raison X ou Y, checker un historique de backend... importer/exporter des posts d’un backend à un autre...
J’ai un champ « nom de backend » mais il ne sert pas de clé. Parce qu’il est personnel (ie: j’aurais pu l’appeler 'dlfp' ou bien 'linuxfr', etc...)
Je prends un exemple, mettons que j’ai pas d’id :
20170205123355 Mozilla... Mussel _o/
c’est un utilisateur authentifié nommé "Mussel", mais on ne sais pas sur backend il est authentifié...
Si j’ai l’id correspondant je peux vérifier que ça correspond au Mussel de tel ou tel backend...
Et puis... de toutes façon... l’id sert, au minimum, à différencier deux ou plus posts dans la même seconde, sur un même backend :) On pourrait différencier les posts avec les autres champs mais ça me paraît moins bien. L’id il est valorisé par le moteur de base de données (et éventuellement les admins du backend), pas par les entrées utilisateurs...
[^] # Re: Beau travail
Posté par Marotte ⛧ . En réponse au journal taab, une tribune sans XML. Évalué à 3. Dernière modification le 28 avril 2017 à 13:07.
Je compte exposer directement le fichier. Je ne comprends pas à quel caching tu fais allusion...
Si je fais un GET sur l’url sans spécifier If-Modified-Since dans l’entête (ou utiliser un ETag) le serveur doit me renvoyer le contenu, que celui-ci ait changé ou pas... et je ne peux pas trop envoyer moi-même cette entête car je n’ai pas de Last-Modified répondu par le serveur (je sais pas trop quelle date mettre...).
Je fais donc un HEAD afin d’avoir juste les entêtes pour savoir si je dois faire un GET pour avoir le contenu ou bien ce n’est pas la peine (dans ce cas je prends mon cache local).
Mais bon. J’ai l’impression que je me prends la tête pour rien et que ça aurait du sens de procéder ainsi si le contenu faisait 4km de long... mais là, limite, je ferais peut-être mieux de récupérer le contenu à chaque fois...
J’ai besoin d’une clé primaire pour mes posts, tous bouchots confondus. Pourquoi ? Parce que je pourrais très bien checker deux fois le même backend, pour une raison X ou Y, checker un historique de backend... importer/exporter des posts d’un backend à un autre...
Du coup, comme je maîtrise LaRache© j’utilise la puissance d’un moteur SQL à coup de 'INSERT OR IGNORE ...', et deux entiers (id et time) comme clé primaire c’est parfait.
J’ai un champ « nom de backend » mais il ne sert pas de clé. Parce qu’il est personnel (ie: j’aurais pu l’appeler 'dlfp' ou bien 'linuxfr', etc...)
Je prends un exemple, mettons que j’ai pas d’id :
20170205123355 Mozilla... Mussel _o/
c’est un utilisateur authentifié nommé "Mussel", mais on ne sais pas sur backend il est authentifié...
Si j’ai l’id correspondant je peux vérifier que ça correspond au Mussel de tel ou tel backend...
Et puis... de toutes façon... l’id sert, au minimum, à différencier deux ou plus posts dans la même seconde, sur un même backend :) On pourrait différencier les posts avec les autres champs mais ça me paraît moins bien. L’id il est valorisé par le moteur de base de données (et éventuellement les admins du backend), pas par les entrées utilisateurs...