2011-11-27 7 views
11

El formato de término externo de Erlang has changed at least once (pero este cambio parece ser anterior al historial almacenado en el repositorio Erlang/OTP github); claramente, podría cambiar en el futuro.¿La definición de formato de términos externos de Erlang es estable? Si no, ¿qué usar?

Sin embargo, como una cuestión práctica, ¿generalmente se considera seguro asumir que este formato es estable ahora? Por "estable" me refiero específicamente a que, para cualquier término T, term_to_binary devolverá el mismo binario en cualquier versión actual o futura de Erlang (no simplemente si devolverá un código binario que binary_to_term volverá a convertir a un término idéntico a T) . Estoy interesado en esta propiedad porque me gustaría almacenar hashes de términos arbitrarios de Erlang en el disco y quiero que los términos idénticos tengan el mismo valor hash ahora y en el futuro.

Si no es seguro asumir que el formato de término es estable, ¿qué utilizan las personas para una serialización de términos eficiente y estable?

Respuesta

7

se ha afirmado que erlang proporcionará compatibilidad para al menos 2 lanzamientos principales. eso significaría que los archivos BEAM, el protocolo de distribución, el formato de término externo, etc. de R14 al menos funcionarán hasta R16.

"We have as a strategy to at least support backwards compatibility 2 major releases back in time."

"In general, we only break backward compatibility in major releases and only for a very good reason and usually after first deprecating the feature one or two releases beforehand."

+0

Aunque estas declaraciones dejan abierta la posibilidad de que el formato de término externo cambie en una versión principal (probablemente solo en una emergencia) o en una versión compatible pero no necesariamente idéntica en un bit, la política es bastante alentadora. ¡Gracias! – willb

1

para la serialización de datos, normalmente elegir entre Google Protocol Buffers y JSON. Ambos son muy estables. Para trabajar con estos formatos desde Erlang uso Piqi, Erlson y mochijson2.

La gran ventaja de Protobuf y JSON es que pueden utilizarse desde otros lenguajes de programación por diseño, mientras que el formato de términos externos de Erlang es más o menos específico de Erlang.

Tenga en cuenta que la representación de cadenas JSON depende de la implementación (caracteres escapados, precisión de coma flotante, espacios en blanco, etc.) y por esta razón puede no ser adecuado para su caso de uso.

Protobuf es menos sencillo de trabajar en comparación con los formatos sin esquema, pero es una herramienta muy bien diseñada y potente.

Aquí hay un par de otros formatos de serialización binarios sin esquema a considerar. No sé qué tan estables son. Puede ocurrir que el formato de término externo de Erlang sea más estable.

2

Erlang: phash2 se garantiza que sea un hash estable de un término Erlang.

No creo que OTP haga la garantía hecha que term_to_binary(T) en vX =: = term_to_binary(T) en vY. Muchas cosas podrían cambiar si introducen nuevos códigos de términos para representaciones optimizadas de las cosas. O si necesitamos agregar cadenas Unicode al ETF o algo así. O en el futuro extremadamente improbable en el que presentamos un nuevo tipo de datos fundamental. Para un ejemplo de cambio que ha sucedido solo en la representación externa (los términos almacenados se comparan iguales, pero no son iguales a los bytes), consulte float_ext frente a new_float_ext.

En términos prácticos, si se apega a átomos, listas, tuplas, enteros, flotantes y binarios, entonces probablemente esté seguro con term_to_binary durante bastante tiempo. Si llega el momento en que cambia su representación de ETF, entonces siempre puede escribir su propia versión de term_to_binary que no cambie con el ETF.

Cuestiones relacionadas