2009-04-02 15 views
5

Necesito la terminología adecuada para un tipo específico de función.¿Terminología para una función determinística sin efectos secundarios?

Supongamos que escribe una función en su base de datos SQL, cuyas entradas y salidas están dentro del alcance de una transacción de base de datos.

Es decir, si llama a esta función en el ámbito de una transacción de base de datos, todos los datos utilizados por la función están disponibles dentro del mismo ámbito. Puede consultar una tabla de base de datos, pero no puede leer un archivo del sistema de archivos o hacer ping a un sitio web, etc. Si llama a la función dos veces en una sola transacción con aislamiento REPEATABLE READ, debe obtener el mismo resultado, incluso si otros clientes están haciendo cambios en la base de datos.

Del mismo modo, la función no tiene efectos secundarios, excepto dentro del mismo ámbito de transacción. Los cambios en el estado fuera del alcance de la transacción de la base de datos no están permitidos. La función no debe enviar correos electrónicos, ni escribir en el sistema de archivos, ni almacenar un valor en memcached, etc. Si la función cambia datos dentro de la base de datos, está bien porque si la transacción de llamada se retrotrae, entonces los efectos de la función son también.

Los argumentos de la función son correctos, ya que básicamente se usan como constantes.

¿Cuál sería el término correcto para una función de este tipo? "Determinista" realmente no parece ser lo suficientemente específico. ¿Cómo describirías esta clase de función?


Gracias por sus respuestas, pero ninguno de ellos es exactamente lo que tenía en mente. Idempotent se acerca más, así que lo marqué como la respuesta aceptada. Pero cada uno de ustedes obtuvo un voto positivo de mi independientemente.

  • funciones puras no tienen efectos secundarios, y su resultado se basa únicamente en sus argumentos. El resultado dado los mismos argumentos es siempre idéntico. Esto no funciona porque las funciones de la base de datos que tengo en mente se pueden basar en el estado de los datos, y la función también puede afectar el estado de los datos.

  • Las funciones de iniciativa pueden devolver un resultado basado en el estado de los datos, y dado el mismo estado de datos, el resultado es siempre idéntico. Pero esto no funciona para lo que tengo en mente exactamente; los efectos de una función idempotente deben dar como resultado un resultado inmutable sin importar cuántas veces se llame a la función. Pero no hay distinción entre los cambios realizados dentro del aislamiento de transacción y los cambios realizados fuera de ese alcance.

Respuesta

5

¿Pregunta acerca de idempotent?

+1

Creo que está buscando algo más fuerte que eso; al menos, con respecto a todos los detalles del alcance que proporcionó, que no son relevantes para la idempotencia. – MarkusQ

+1

No, no creo que haya querido llamar a la función sobre sus resultados ... que es lo que le importa a la idempotencia. – Varkhan

+0

@Varkhan, estás usando el sentido matemático de idempotent, pero S. Lott está usando una definición relacionada común en la programación. Lee su enlace – RossFabricant

1

Hasta el cuarto párrafo, pensaba que era solo una función pura con la transacción como un argumento implícito. Pero cuando dice:

la función no tiene efectos secundarios, excepto dentro del mismo ámbito de transacción. Los cambios en el estado fuera del alcance de la transacción de la base de datos no están permitidos.

No estoy tan seguro. ¿Quiere decir que podría hacer los cambios dentro de la transacción, pero no estar al tanto de ellos en una futura llamada?¿Cómo se puede conciliar eso con:

Si se llama a la función dos veces en una sola transacción con el aislamiento LEER REPETIBLE, debería obtener el mismo resultado

En otras palabras, ¿está limitando la in- efectos secundarios de la transacción a las asignaciones (como establecer una bandera en verdadero) que tienen el mismo efecto si se hace varias veces?

+0

Creo que "alcance de transacción" significa dentro de la función. Una función puede cambiar su estado interno sin dejar de ser pura para los llamantes. Piense que no afecta ningún estado al que cualquier otra cosa pueda llegar. –

+0

Todavía creo que la función pura es la más apropiada (incluso si no es perfecta) para usar en ese contexto. – Varkhan

+0

No, quise decir el alcance de la transacción. Si la función realiza un cambio en los datos, una llamada de función posterior dentro de la misma transacción debería ver el cambio. –

6

También puede llamar a estos pure functions.

+1

No, porque tiene efectos secundarios que persisten si la transacción se compromete; ver el cuarto párrafo. – MarkusQ

+1

También el tipo de función que tengo en mente no es una función pura porque podría dar resultados diferentes dados los mismos argumentos, debido a los datos en la base de datos. P.ej. una función como 'totalOrdersForMonth (11)'. –

1

Aquí hay dos conceptos diferentes, por lo que puede que necesite combinar varios términos por la misma razón por la que no hay un solo adjetivo que describa la "casa circular roja".

> No se permiten cambios en el estado fuera del alcance de la transacción de la base de datos.

> Si la función cambia los datos dentro de la base de datos, está bien, porque si la transacción de llamada se retrotrae, entonces los efectos de la función también lo son.

Solo hay "alcance de la base de datos" y "alcance de la sesión". Una función no tiene ningún concepto del "alcance de la transacción". Una función puede usarse dentro de una transacción o fuera de esa transacción, pero desde el punto de vista de la función no habría diferencia.

A los ojos de una función, el "alcance de la transacción" es exactamente el "alcance de la base de datos". No se supone que las cosas dentro de una transacción no confirmada que estar comprometido, y puesto que se aplica a todas las transacciones, no hay nada acerca especial:

Si se llama a la función dos veces en una sola transacción con el aislamiento LEER REPETIBLE, debe obtener la mismo resultado, incluso si otros clientes están haciendo cambios en la base de datos.

porque eso describe la transacción, no la función. Podemos ignorar con seguridad cualquier descripción que tenga que ver con "transacciones".

> Se puede consultar una tabla de base de datos, pero no puede leer un archivo del sistema de archivos, o ping a un sitio web, etc.

> Cambios en el estado fuera del alcance de la transacción de base de datos no están permitidos. La función no debe enviar mensajes de correo electrónico, ni escribir en el sistema de archivos, ni almacenar un valor en memcached, etc.

> Si la función cambia de datos dentro de la base de datos, eso está bien porque si la transacción vocación se deshace, entonces los efectos de la función son demasiado .

> Pero no hay distinción entre los cambios realizados en transacción [base de datos] aislamiento y los cambios realizados fuera de ese alcance.

El término más cercano probablemente sería "database-local".

> mismo modo, la función no tiene efectos secundarios, excepto dentro de la misma alcance transacción [base de datos].

Lo que significa que tiene efectos secundarios.

> las funciones de la base de datos que tengo en mente pueden basarse en el estado de los datos, y la función también puede afectar el estado de los datos.

El término más cercano es "no-nullipotent", o "posiblemente-stateful".

Por lo tanto, la conclusión es "A db-local non-nullipotent function".

+1

¡Gracias por la respuesta bien razonada! –

Cuestiones relacionadas