warnings from hairtigger on postgres

[ghost]

Hello, I'm seeing the following warning in schema.db:

WARNING: generating adapter-specific definition for posts_after_update__trigger due to a mismatch.

either there's a bug in hairtrigger or you've messed up your migrations and/or db :-/

Seems related to dependency versions, because in another installation of rails I see this instead:

no candidate create_trigger statement could be found, creating an adapter-specific one

https://github.com/rubyrailhead/hairtriggertest/blob/master/db/schema.rb#L40

Complete project showing the issue here:
https://github.com/rubyrailhead/hairtriggertest
see especially https://github.com/rubyrailhead/hairtriggertest/blob/master/db/migrate/20150528170434_add_localtimestamp_to_posts.rb

[jenseng]

I'll dig into this a bit to see if I can track it down.

I suspect part (or all?) of the problem is that it can't infer the full trigger definition from the migration... hairtrigger's schema dumping code reads the migrations (using ruby_parser) and pulls out create_trigger calls; if the generated sql of that call matches what's in the db, you'll get the expected create_trigger in schema.rb ... but in your migration, the second create_trigger passes an instance variable as an arg to of(), so I'm not surprised that one doesn't match up (since it's just reading the code, not running it in the context of the migration).

Did you see a warning like Error reading triggers in db/migrate/20150528170434_add_localtimestamp_to_posts.rb when you run migrations? Any additional information along with that?

One other thing, if your app only ever uses a postgres db, the warnings are not a huge deal. Your triggers are still accurately represented in schema.rb, you just couldn't use it to set up a sqlite or mysql db.

[ghost]

Hi @jenseng , apologies for taking so long to get back to you, just noticed you wrote back.

1. no, I don't see any warnings when running the migrations: here's the exact output:

$ rake db:migrate
== 20150528170319 CreatePosts: migrating ======================================
-- create_table(:posts)
   -> 0.0033s
== 20150528170319 CreatePosts: migrated (0.0033s) =============================

== 20150528170434 AddLocaltimestampToPosts: migrating =========================
-- add_column(:posts, :dachtimestamp, :timestamp)
   -> 0.0005s
-- execute("UPDATE posts SET dachtimestamp=updated_at")
   -> 0.0003s
-- create_trigger("posts_after_insert__trigger", {:compatibility=>1})
   -> 0.0001s
-- create_trigger("posts_after_update__trigger", {:compatibility=>1})
   -> 0.0000s
== 20150528170434 AddLocaltimestampToPosts: migrated (0.0078s) ================

2. good to hear that there's no issue with postgres and these warnings, ... however my co-workers have noticed and asked about the warnings. We'd love to see them go away.

3. also it's weird to me that we only get those warnings on the update trigger and not on the insert trigger. That does line up with your theory about the of() clause though.

4. Please let me know if there's anything I can do to help you debug or understand this further! I'm happy to run tests on our environment if you have changes you want me to test against the repo https://github.com/rubyrailhead/hairtriggertest (or other)

Thanks very much,
"Ruby"

[ghost]

Hello, @jenseng , just a friendly reminder that we'd love to resolve this warning and I'm totally willing to assist. Best, Ruby

[jenseng]

@rubyrailhead sorry for the radio silence here, and thanks for the info you provided. I'll dig into this in the next day or so. For starters i'll probably see about turning down the warnings a bit.

[DavidRawk-Blake]

Still getting this warning today.

# WARNING: generating adapter-specific definition for user_after_update_row_tr due to a mismatch.
  # either there's a bug in hairtrigger or you've messed up your migrations and/or db :-/

[toydestroyer]

I encountered the same issue just now. After some debugging, I found that the problem was caused by calling create_trigger in the change method. The issue was resolved when I explicitly defined the up and down methods.