New function triggers proposal

[ranshid]

This outline a new feature proposal for introducing function triggers.
Triggers are persistent procedures which are executed in response to some keyspace event. Unlike the existing Keyspace Notifications Mechanism they offer an administrator the ability to place extending logic on simple client operations. Currently clients have almost complete ownership of the actions made on the data. The addition of Functions added the ability to encapsulate logic in a maintainable functions library, thus managing the scope of operations clients are using. According to the function's philosophy, the client will use functions to operate the complete set of actions, making this feature require to migrate the client to use the specific functions and maintain the logic across different function-library versions. Use of functions is also limited to the context of operation initiated by the client, while there are different database related events which are out of any specific client context
(expirations, evictions etc...)
Function triggers comes to provide the ability to define a specific logic to be executed on a specific keyspace change thus being able to fully own and control the data modifications without requiring the external clients to be aware of the extended logic.
This will allow users to place different actions to follow some keyspace event.
As being integrated in the existing Functions infrastructure, Triggers are persisted as part of the user data, and so replicated.

[madolson]

What is a redis?

[daniel-house]

Suggested change

	**total_trigger_calls -** the number of general tri9gger calls. this will not be a teardown list of calls per trigger function (this can be taken from the function list command as will be explained later)
	**total_trigger_calls -** the number of general trigger calls. this will not be a teardown list of calls per trigger function (this can be taken from the function list command as will be explained later)

[daniel-house]

On the one hand, allowing execution of one trigger to cause execution of another trigger leads to a variety of problems, including endless loops.

On the other hand, my previous experience with triggers in other environments taught me that one of the biggest values of triggers was the ability to think about the system in a declarative manner, instead of an imperative manner.

For example, trigger T1 could promise that every LPUSH operation on key JOBS would be accompanied by an LPUSH on key LOG, where the data pushed onto LOG included a timestamp and the user's ID. Trigger T2 could promise that the key LOG_TOO_LONG would be set to TRUE exactly when LLEN LOG > 1000. But this only works if T1 can trigger T2.

This area deserves a lot of detailed analysis.

[daniel-house]

When a module depends on a callback, this will break the module.

[daniel-house]

It seems to me that we need to choose between a super-safe approach, which will greatly limit what triggers can do, and a super-dangerous approach, which allows triggers to do anything and demands great caution when using them. This feels like the same choice we make between a language like Java and one like C. (Or between using a butter knife and a chain saw. Most of the time I want my knives to be as sharp as possible.) It strikes me as very confusing if we pick something in the middle.

What do others want? A bike with or without training wheels? Safety or power? Many of our later decisions will flow from this basic principle.

[ranshid]

@valkey-io/core-team I moved this to RFC valkey-io/valkey-rfc#9 and added some usecases. we can continue there according to the new RFC process