Numéro de séquence bug dans CouchDB 2 ou existe-t-il un autre moyen de comparer les numéros de séquence?

Question

Je suis en train de creuser plus profondément dans CouchDB 2 et je trouve des commandes inattendues avec des numéros de séquence. Dans un cas, je l'ai trouvé qu'un changement rapide dans un flux de _changes a le numéro de séquence

99-g1AAAAI-eJyd0EsOgjAQBuAGiI-dN9C9LmrBwqzkJtrSNkgQV6z1JnoTvYneBEvbhA0aMU1mkj6-_NMSITTJfYFm2anOcsFT10mpTzyG-LxpmiL32eqoN8aEAcWE9dz_jPCFrnzrHGQchiFM4kSgaV0JqQ6VFF-AtAV2DggMgCEGxrNhQfatc3bOyDiKUalg2EBVoCu66KapazcUh41e69-GssjNIvcWWRokk2oNofwj0MNazy4QFURhGQ0J9LKI-SHPIBHEgiak51nxBhxnrRk 

Le dernier numéro de séquence dans mes _changes aliments pour animaux, pour la même DB, est

228-g1AAAAJFeJyd0EkOgjAUBuAGTJCdN9AjlIKFruQm2jFAEFes9SZ6E72J3gQ7JW7QCGnyXtLhy-vfAgCWVSjAip96XglW-o5afRJQwNbDMDRVSOuj3ogQJRgiOnL_O8I2urKdd4B1KCRpkRcCxH0npKo7KX4ApQH2HogsAElOKOPTBjkY5-yd2DqKYqnItA91C13BRTdNXY0VWouRrV7JDOvmrLuxlLW4VAlJ5Qzr4aznJ2wskIIy-y9sh7wcYoMKLJKRXOACjTxr3uHcsBE 

Dans un navigateur console, ce qui suit est faux

'228-g1AAAAJFeJyd0EkOgjAUBuAGTJCdN9AjlIKFruQm2jFAEFes9SZ6E72J3gQ7JW7QCGnyXtLhy-vfAgCWVSjAip96XglW-o5afRJQwNbDMDRVSOuj3ogQJRgiOnL_O8I2urKdd4B1KCRpkRcCxH0npKo7KX4ApQH2HogsAElOKOPTBjkY5-yd2DqKYqnItA91C13BRTdNXY0VWouRrV7JDOvmrLuxlLW4VAlJ5Qzr4aznJ2wskIIy-y9sh7wcYoMKLJKRXOACjTxr3uHcsBE' > '99-g1AAAAI-eJyd0EsOgjAQBuAGiI-dN9C9LmrBwqzkJtrSNkgQV6z1JnoTvYneBEvbhA0aMU1mkj6-_NMSITTJfYFm2anOcsFT10mpTzyG-LxpmiL32eqoN8aEAcWE9dz_jPCFrnzrHGQchiFM4kSgaV0JqQ6VFF-AtAV2DggMgCEGxrNhQfatc3bOyDiKUalg2EBVoCu66KapazcUh41e69-GssjNIvcWWRokk2oNofwj0MNazy4QFURhGQ0J9LKI-SHPIBHEgiak51nxBhxnrRk' 

est-ce un bug ou ai-je besoin d'utiliser une autre méthode pour comparer les numéros de séquence? En regardant les autres numéros de séquence dans mon flux _changes, il semble qu'ils soient généralement ordonnés comme je l'attendais, mais dans ce cas, il apparaît que lorsque le premier numéro, par ex. 99, saute de 2 chiffres à 3 chiffres, les pauses de commande. Si vous résumez ceci à un simple exemple de comparaison de chaîne, vous pouvez voir que '228'> '99' => false

Answer 1

La réponse suivante contient des extraits d'un fil d'e-mail avec @rnewson. J'espère que cela aide quelqu'un d'autre à comprendre les numéros de séquence dans CouchDB 2. Merci, Robert!

L'arrière-plan:

Il n'y a pas moyen facile de les comparer à 2,0 et aucune exigence pour les en ordre. En résumé, ils ne sont pas conçus pour être examinés ou comparés à l'extérieur de couchdb; Traitez-les opaque. Le numéro sur le front est la somme des séquences de mise à jour individuelles codées dans la deuxième partie et existe uniquement pour tromper les anciennes versions de le réplicateur de couchdb en créant des points de contrôle. La dernière moitié de la chaîne de séquence est une liste codée de {nœuds, range, seq} tuples (où seq est la valeur entière que vous connaissez de versions antérieures à la version 2.0). Lorsqu'une chaîne de séquence est retransmise, en tant que paramètre depuis =, couchdb décode cette chaîne et transmet la valeur entière appropriée du segment au fragment individuel. Tout ce qui a été dit, en général, le nombre avant devrait augmenter. Les chaînes entières ne sont pas comparables, puisqu'il n'y a pas d'ordre défini dans la liste codée (donc deux chaînes peuvent être générées codées différemment mais décodées dans la même liste de tuples, seulement dans un ordre différent de ).

Un autre aspect à ceci est que la modification des flux n'est pas totalement ordonnée. Pour un fragment donné est totalement ordonné (un fragment étant identique à une base de données pré 2.0 avec une séquence entière), couchdb ne mélange pas cette sortie (bien que l'exactitude de la réplication soit être retenue si c'est le cas). Une base de données en cluster est composée de plusieurs fragments , bien que (la valeur 'q', par défaut 4 iirc). Le flux de modifications groupées combine ces flux de modifications distincts en un seul, , mais ne fait aucun effort pour imposer un ordre total par rapport à cela.Nous ne le faisons pas parce que ce serait cher et inutile.

La solution si vous avez besoin d'écouter sur un flux de _changes puis redémarrez de l'endroit où vous l'avez laissé plus tard:

L'algorithme de consommation correctement les changements alimentation est:

1. read/nomdbb/_changements
2. traiter chaque ligne idempotently
3. périodiquement (tous les X secondes ou que toutes les lignes X) stocker les « suivants » valeur de la dernière ligne vous avez traité

Si vous avez un accident jamais, ou si vous ne l'utilisez continue = true, vous pouvez faire cette même procédure mais modifiée à l'étape 1;

révisé 1. lecture/dbname/_changes? Depuis = X

où X est la valeur que vous avez enregistré à l'étape 3. Si vous n'êtes pas en mode Continu alors vous pouvez enregistrer la valeur « last_seq » à fin de la consommation de la réponse non continue. Vous courez le risque de retraiter beaucoup plus d'articles, cependant.

Avec ce schéma (que le réplicateur et tous les indexeurs suivent), vous ne se soucie pas si les résultats sont en désordre, vous n'avez pas besoin de comparer deux valeurs quelconques. Vous devez vous assurer que vous pouvez traiter correctement le même changement plusieurs fois. Pour un exemple de cela, considérons le réplicateur, quand voit une ligne à partir d'un flux de changements, il demande à la base de données cible si contient les valeurs _id et _rev de cette ligne. Si c'est le cas, le réplicateur passe à la ligne suivante. Si ce n'est pas le cas, il essaie d'écrire le document dans cette ligne vers la base de données cible. Dans le cas d'un plantage , et donc un appel à _changes avec une valeur seq avant traitant cette ligne, il demandera à la base de données cible si elle a à nouveau le _id/_rev, seulement cette fois la cible dira oui.