Allow setting boolean conditions (like in permissions).
One should be able to say things like trigger the webhook only if is_cancelled=false
Use case
I came across this while building an online-ordering app in a 3factor style.
When is_cancelled in the order table is set to true from the client, you can't stop the event cycle unless you add the filter in all the serverless functions which could complicate things a bit once there are more filters.
It will be cool to have filters on the server itself.
cc: @tirumaraiselvan
:+1:
I think this can be a powerful feature which offloads some of the (serverless) code into a config instead.
@coco98 thoughts?
That is exactly what I'm facing. I'm using a trigger to call a lambda for image manipulation, which saves more info in the same row later on. I need to have a flag to avoid recursion, but the lambda still needs to be called twice. If I could move the check to the Hasura sever, I would save half of executions. Must be different ways to accomplish the same result though, but it's just one use case I wanted to share
@schettino Can you shed more light into the event trigger configuration? I am guessing you are calling the trigger on UPDATE. In that case having specific "listen columns" might be a possible solution to avoid calling the trigger on any update: https://docs.hasura.io/1.0/graphql/manual/event-triggers/create-trigger.html#listen-columns-for-update
It's indeed a possible solution, but there might be another surfaces it might not cover. On my case, I was storing the public image URL, which would trigger the lambda on every update made through the client. However, the url started to change as a step within the Lambda execution and, saving the new url back into that row would trigger its execution again. I could create more columns, like an image id and only listen to its change, but having this sort of filter would be handy, specially for more complex cases than generating thumbnails. What do you think?
@schettino Yes, I agree fully.
I have a need for this. Our backend has several mutations that it only needs to be alerted for in the case of a boolean being either true or false. Instead, it gets an alert on updates both ways, which doubles the amount of requests sent between hasura and the microservice for that particular event trigger.
Totally agree to every one else replied. Best would be to have a similar interface like permissions based on columns of the table to be changed in certain condition. This would reduce the webhook logic and aligns with the setup of Hasura in general
Need this as well, any updates on this?
I saw the change of label 27 days ago, any update about this?
Any update? Postgres enum on my database column causes a lot of trigger on the same webook, makes unimportant logs with unsucess responses there.
Tracking another related request to Add prevent rule as mentioned here https://github.com/hasura/graphql-engine/issues/5322#issue-652512635 by @revskill10.
So, how it is going on?
I also need this. I intend to automatically index records into elastic search, triggered off of create, update and delete events. However, if I wanted to write back to the database in that web hook, it would trigger a loop. I also do not want to waste thousands of lambda executions for no reason. Please!
This feature has become increasingly important for us due to what seems to be a memory leak with event triggers: https://github.com/hasura/graphql-engine/issues/4077#issuecomment-690153050
One work around is by editing the trigger function and adding the conditional there like this
create function "notify_hasura_employee_hired_UPDATE"() returns trigger
language plpgsql
as
$$
DECLARE
_old record;
_new record;
_data json;
BEGIN
IF NOT NEW.hiring_confirmed THEN -- this prevents the event from triggering if the condition is not satisfied
RETURN NULL;
end if;
IF TG_OP = 'UPDATE' THEN
_old := row((SELECT "e" FROM (SELECT OLD."hiring_confirmed" , OLD."hiring_confirmed_by" , OLD."hiring_confirmed_on" ) AS "e" ) );
_new := row((SELECT "e" FROM (SELECT NEW."hiring_confirmed" , NEW."hiring_confirmed_by" , NEW."hiring_confirmed_on" ) AS "e" ) );
ELSE
/* initialize _old and _new with dummy values for INSERT and UPDATE events*/
_old := row((select 1));
_new := row((select 1));
END IF;
_data := json_build_object(
'old', row_to_json(OLD ),
'new', row_to_json(NEW )
);
BEGIN
IF (TG_OP <> 'UPDATE') OR (_old <> _new) THEN
PERFORM hdb_catalog.insert_event_log(CAST(TG_TABLE_SCHEMA AS text), CAST(TG_TABLE_NAME AS text), CAST('employee_hired' AS text), TG_OP, _data);
END IF;
EXCEPTION WHEN undefined_function THEN
IF (TG_OP <> 'UPDATE') OR (_old *<> _new) THEN
PERFORM hdb_catalog.insert_event_log(CAST(TG_TABLE_SCHEMA AS text), CAST(TG_TABLE_NAME AS text), CAST('employee_hired' AS text), TG_OP, _data);
END IF;
END;
RETURN NULL;
END;
$$;
alter function "notify_hasura_employee_hired_UPDATE"() owner to postgres;
my only problem is how do i make this part of my migration? and how do i ensure hasura doesn't override it? for example re applying the metadata removes the changes i made to the function
What about finding the Hasura Event trigger you need conditions for by running, select * from information_schema.triggers, and then dropping that trigger, and recreating it via SQL with the appropriate condition? As long as the trigger calls the correct function, how is creating the trigger manually via SQL different than creating it via the Hasura interface? Isn't an Event just a simple trigger calling a specialized function?
I would also like to see filters added to the Hasura event support. Any plans to tackle this?
I think Postgres's when conditions on triggers might help us achieve this: https://www.postgresql.org/docs/12/sql-createtrigger.html