Terminology for a deterministic function with no side-effects?

Question

I need the proper terminology for a specific type of function.

Suppose you write a function in your SQL database, whose inputs and outputs are contained within the scope of a database transaction.

That is, if you call this function in the scope of a database transaction, all the data used by the function is available within the same scope. It can query a database table, but it can't read a file from the filesystem, or ping a web site, etc. If you call the function twice within a single transaction with REPEATABLE READ isolation, you should get the same result, even if other clients are making changes in the database.

Likewise, the function has no side-effects, except within the same transaction scope. Changes in state outside the scope of the database transaction are not allowed. The function shouldn't send emails, nor write to the filesystem, nor store a value in memcached, etc. If the function changes data within the database, that's okay because if the calling transaction is rolled back, then the effects of the function are too.

The arguments of the function are okay, since they're basically used as constants.

What would be the proper term for a function of this type? "Deterministic" doesn't really seem to be specific enough. How would you describe this class of function?

---

Thanks for your answers, but none of them is exactly what I had in mind. Idempotent gets closest, so I marked that as the accepted answer. But each of you got an upvote from me regardless.

• Pure functions have no side-effects, and their result is based solely on their arguments. The result given the same arguments is always identical. This doesn't work because the database functions I have in mind can be based on the state of data, and the function can also affect the state of data.

• Idempotent functions can return a result based on the state of data, and given the same state of data, the result is always identical. But this doesn't work for what I have in mind exactly; the effects of an idempotent functions must result in an unchanging result no matter how many times the function is called. But there's no distinction between changes made within transaction isolation and changes made external to that scope.

Answer 1

Are you asking about idempotent?

Answer 2

You can also call these pure functions.

Answer 3

Up to the forth paragraph, I was thinking it was just a pure function with the transaction as an implicit argument. But when you say:

the function has no side-effects, except within the same transaction scope. Changes in state outside the scope of the database transaction are not allowed.

I'm not so sure. Do you mean that it could make changes within the transaction but not be cognizant of them on a future call? How do you square that with:

If you call the function twice within a single transaction with REPEATABLE READ isolation, you should get the same result

In other words, are you limiting the in-transaction side effects to assignments (such as setting a flag to true) that have the same effect if done multiple times?

Answer 4

There are two different concepts here so you may need to combine multiple terms for the same reason there's no one adjective to describe "red circular house".

> Changes in state outside the scope of the database transaction are not allowed.

> If the function changes data within the database, that's okay because if the calling transaction is rolled back, then the effects of the function are too.

There is only "database scope" and "session scope". A function has no concept of the "transaction scope". A function can be used within a transaction or outside of that transaction, yet from the function's point of view there would be no difference.

In the eyes of a function, the "transaction scope" is exactly the "database scope". Things within an uncommitted transaction is not supposed to be committed, and since that applies to all transactions, there's nothing special about:

If you call the function twice within a single transaction with REPEATABLE READ isolation, you should get the same result, even if other clients are making changes in the database.

because that's describing the transaction, not the function. We can safely ignore any description that has to do with "transactions".

> It can query a database table, but it can't read a file from the filesystem, or ping a web site, etc.

> Changes in state outside the scope of the database transaction are not allowed. The function shouldn't send emails, nor write to the filesystem, nor store a value in memcached, etc.

> If the function changes data within the database, that's okay because if the calling transaction is rolled back, then the effects of the function are too.

> But there's no distinction between changes made within transaction [database] isolation and changes made external to that scope.

The closest term would probably be "database-local".

> Likewise, the function has no side-effects, except within the same transaction [database] scope.

Which means it has side-effects.

> the database functions I have in mind can be based on the state of data, and the function can also affect the state of data.

The closest term is "non-nullipotent", or "possibly-stateful".

So the conclusion is "A db-local non-nullipotent function".