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 em> changer dans l'avenir. P>
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 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? P> t code>,
term_to_binary code> 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 code> sera reconverti sur un terme identique à
t code>). 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. P>
3 Réponses :
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. P>
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!
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 . p>
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. p>
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. P>
Protobuf est moins simple pour fonctionner avec des formats de schéma, mais c'est un outil très bien conçu et puissant. P>
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. P>
Erlang: PHASH2 est garantie d'être un hachage stable d'un terme erlang. p>
Je ne pense pas que OTP fait la garantie rendue que 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 (t) code> dans vx =: =
term_to_binaire (t) code> 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 code> vs.
new_float_ext p>. P>.
term_to_binary code> 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 code> qui ne change pas avec l'ETF. P>