views:

252

answers:

3

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.

+5  A: 

Are you asking about idempotent?

S.Lott
I think he's looking for something stronger than that; at least, with regard to all the scoping details he provided, which aren't relevant to idempotency.
MarkusQ
No, I don't think he meant anything about calling the function on its results... which is what idempotency cares about.
Varkhan
@Varkhan, you are using the math sense of idempotent, but S. Lott is using a related definition common in programming. Read his link.
RossFabricant
@Varkhan idempotent in the sense that the global state is a hidden parameter and part of the result.
MarkusQ
It's okay for the type of function I have in mind to INSERT a new database row, since that can be rolled back. But it can't send an email, for instance, because that's changing state outside the scope of the database transaction.
Bill Karwin
+1  A: 

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?

MarkusQ
I think "transaction scope" means within the function. A function can change its internal state while still remaining pure to callers. Think of it as not affecting any state anything else can get to.
David Thornley
I still think pure function is the most appropriate (even if it is not perfect) to use in that context.
Varkhan
No, I meant transaction scope. If the function makes a change to data, a subsequent function call within the same transaction should see the change.
Bill Karwin
+6  A: 

You can also call these pure functions.

RossFabricant
No, because it has side effects that persist if the transaction commits; see the forth paragraph.
MarkusQ
Also the type of function I have in mind is not a pure function because it could give different results given the same arguments, due to data in the database. E.g. a function like `totalOrdersForMonth(11)`.
Bill Karwin