graphql-engine: Applying migrations not working as expected

I´m trying a simple backup / restore on the same database with hasura CLI

After creating the migrations, I´ve deleted all my tables in Hasura and wanted to recreate them by applying the migrations, but I´m running into this issue:

File: '1578000210752_init\up.sql'
{
    "sql": "CREATE FUNCTION public.set_current_timestamp_updated_at() RETURNS trigger\n    LANGUAGE plpgsql\n    AS $$\nDECLARE\n  _new record;\nBEGIN\n  _new := NEW;\n  _new
.\"updated_at\" = NOW();\n  RETURN _new;\nEND;\n$$;\nCREATE TABLE public.team (\n    id integer NOT NULL,\n    created_at timestamp with time zone DEFAULT now() NOT NULL,\n
  updated_at timestamp with time zone DEFAULT now() NOT NULL,\n    name text NOT NULL\n);\nCREATE SEQUENCE public.team_id_seq\n    AS integer\n    START WITH 1\n    INCREMENT
 BY 1\n    NO MINVALUE\n    NO MAXVALUE\n    CACHE 1;\nALTER SEQUENCE public.team_id_seq OWNED BY public.team.id;\nCREATE TABLE public.\"user\" (\n    id integer NOT NULL,\n
   created_at timestamp with time zone DEFAULT now() NOT NULL,\n    updated_at timestamp with time zone DEFAULT now() NOT NULL,\n    name text,\n    team_id integer\n);\nCREA
TE SEQUENCE public.user_id_seq\n    AS integer\n    START WITH 1\n    INCREMENT BY 1\n    NO MINVALUE\n    NO MAXVALUE\n    CACHE 1;\nALTER SEQUENCE public.user_id_seq OWNED
BY public.\"user\".id;\nALTER TABLE ONLY public.team ALTER COLUMN id SET DEFAULT nextval('public.team_id_seq'::regclass);\nALTER TABLE ONLY public.\"user\" ALTER COLUMN id SE
T DEFAULT nextval('public.user_id_seq'::regclass);\nALTER TABLE ONLY public.team\n    ADD CONSTRAINT team_pkey PRIMARY KEY (id);\nALTER TABLE ONLY public.\"user\"\n    ADD CO
NSTRAINT user_pkey PRIMARY KEY (id);\nCREATE TRIGGER set_public_team_updated_at BEFORE UPDATE ON public.team FOR EACH ROW EXECUTE PROCEDURE public.set_current_timestamp_updat
ed_at();\nCOMMENT ON TRIGGER set_public_team_updated_at ON public.team IS 'trigger to set value of column \"updated_at\" to current timestamp on row update';\nCREATE TRIGGER
set_public_user_updated_at BEFORE UPDATE ON public.\"user\" FOR EACH ROW EXECUTE PROCEDURE public.set_current_timestamp_updated_at();\nCOMMENT ON TRIGGER set_public_user_upda
ted_at ON public.\"user\" IS 'trigger to set value of column \"updated_at\" to current timestamp on row update';\nALTER TABLE ONLY public.\"user\"\n    ADD CONSTRAINT user_te
am_id_fkey FOREIGN KEY (team_id) REFERENCES public.team(id) ON UPDATE RESTRICT ON DELETE RESTRICT;\n"
}
[42723] FatalError: function "set_current_timestamp_updated_at" already exists with same argument types

Are there any restrictions applying the migrations that I´m not aware of?

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 6
  • Comments: 21 (5 by maintainers)

Most upvoted comments

Any update on this issue?

Execute this in the hasura SQL console if you run into this DROP FUNCTION public.set_current_timestamp_updated_at;

I encountered this issue when created a new server instance, I have an existing database that is used by hasura on previous server and when I created a new instance to use the same database the error happens

{"exec_status":"FatalError","hint":null,"message":"function \"gen_hasura_uuid\" already exists with same argument types","status_code":"42723","description":null}

I have the same issue as @amitava82 and I only have 1 migration called “init”.

@marionschleifer Why did you close this issue? Can you please reopen because I don’t see any solution here yet.

I think I had that same issue as my issue as I described in https://github.com/hasura/graphql-engine/issues/3632. I just saw it once and forgot exactly what the error was.

I’m not sure if its the same bug I encountered, but if it is, basically the answer to solving this is to only have one folder in migrations with init in it. That means, you may have multiple folders e.g. 15780405824_init and 1578040748052_init. You should delete one of them (probably the one that isn’t the first one you made). Basically there shouldn’t be more than one up.sql file in the migrations.