11
votes

La définition de format external du terme Erlang est-elle stable? Sinon, quoi utiliser?

Le format de durée externe Erlang a changé au moins une fois (mais ce changement semble prédimer l'historique stocké dans le référentiel GitHub Erlang / OTP); Clairement, il pourrait changer dans l'avenir.

Cependant, comme une question pratique, est-il généralement considéré comme sûr de supposer que ce format est stable maintenant? Par "stable", je veux dire spécifiquement que, pour tout terme t , term_to_binary retournera le même binaire dans n'importe quelle version actuelle ou future d'Erlang (pas simplement si elle reviendra Un binaire que binaire_to_term sera reconverti sur un terme identique à t ). Je suis intéressé par cette propriété parce que j'aimerais stocker des hachages de termes arbitraires erlang sur le disque et je veux des termes identiques pour avoir la même valeur de hachage maintenant et à l'avenir.

S'il n'est pas sûr de supposer que le terme format est stable, quelles sont les personnes utilisatrices pour une série de sérialisation efficace et stable?


0 commentaires

3 Réponses :


8
votes

Il a été déclaré que Erlang fournira une compatibilité pour au moins deux versions majeures. Cela signifierait que les fichiers de faisceau, le protocole de distribution, le format termel extérieur, etc. de R14 travailleront au moins jusqu'à R16.

"Nous avons une stratégie pour soutenir au moins la compatibilité de la route 2 libère dans le temps. "

"En général, nous ne cassons que la compatibilité en arrière dans les principales versions et seulement pour une très bonne raison et généralement après la première amorce la fonctionnalité d'une ou deux versions au préalable. "


1 commentaires

Bien que ces déclarations laissent la possibilité d'ouvrir la possibilité que le format à terme externe change dans une version majeure (probablement uniquement en cas d'urgence) ou de manière compatible mais pas nécessairement bit-identielle, la politique est assez encourageante. Merci!



1
votes

Pour la sérialisation des données, je choisis généralement entre les tampons de Google Protocol et JSON. Les deux sont très stables. Pour travailler avec ces formats d'Erlang, j'utilise PIQI , erlson et mochijson2 .

Un grand avantage de Protobuf et JSON est qu'ils peuvent être utilisés à partir d'autres langages de programmation par design, alors que Erlang externe Term Format est plus ou moins spécifique à Erlang.

Notez que la représentation de chaîne JSON dépend de la mise en œuvre - dépendante de la mise en oeuvre (caractères échappés, une précision de point flottant, des espaces, etc.) et pour cette raison, il peut ne pas convenir à votre cas d'utilisation.

Protobuf est moins simple pour fonctionner avec des formats de schéma, mais c'est un outil très bien conçu et puissant.

Voici quelques autres formats de sérialisation binaire schémas à considérer. Je ne sais pas à quel point ils sont stables. Il peut s'agir de ce format externe Erlang externe est plus stable.


0 commentaires

3
votes

Erlang: PHASH2 est garantie d'être un hachage stable d'un terme erlang.

Je ne pense pas que OTP fait la garantie rendue que term_to_binary (t) dans vx =: = term_to_binaire (t) dans VY. Beaucoup de choses pourraient changer si elles introduisent de nouveaux codes à terme pour des représentations optimisées des choses. Ou si nous devons ajouter des chaînes Unicode à l'ETF ou quelque chose. Ou dans l'avenir improbablement improbable dans lequel nous introduisons un nouveau type de données fondamental. Pour un exemple de changement qui s'est produit uniquement dans la représentation externe uniquement (les termes stockés comparent égal, mais ne sont pas égaux égaux) voir float_ext vs. new_float_ext . .

En termes pratiques, si vous collez des atomes, des listes, des tuples, des entiers, des flotteurs et des binaires, vous êtes probablement en sécurité avec term_to_binary pendant un certain temps. Si le temps vient que leur représentation ETF change, vous pouvez toujours écrire votre propre version de term_to_binary qui ne change pas avec l'ETF.


0 commentaires