#1429 sync_schema does not sync triggers

[HansH]

In order to deal with #1429, I made two changes:

1. Instead of using CREATE TRIGGER IF NOT EXISTS..., it now uses DROP TRIGGER IF EXISTS <triggername>;CREATE TRIGGER <triggername>..... This ensures that the trigger is recreated as specified in the make_storage call.
2. I added a method trigger_names, similar to the method table_names. This can be used to see which triggers actually exist in the database, so you can decide e.g. to use drop_trigger() to delete any triggers that you do not want.

I also added tests to test these changes.

[fnc12]

hi @HansH . Thanks for creating this PR. I got one concern about it: if we are going to drop trigger anyway in sync_schema then this PR cannot be accepted cause it is not how sync intended to work. If you need this behavior for your specific domain/project please use storage.drop_trigger instead and them storage.sync_schema

[HansH]

If this is not how sync is intended to work, can you expand on how it is intended to work? Note that it immediately recreates the triggers that it drops. So in effect nothing is dropped, only changed, which I would expect to be the intended behavior of sync.

[fnc12]

If this is not how sync is intended to work, can you expand on how it is intended to work?

it has to compare real triggers from db with ones specified in make_storage and make db's ones to be the same as described in make_storage. Just like it works with tables. Imagine if every sync_schema drops all tables EVERY time. I know that triggers do not contain data but anyway we don't have to remove entities if we can skip removal.

Note that it immediately recreates the triggers that it drops.

I see. But it does drops even when no difference found. Table sync works differently.

So in effect nothing is dropped, only changed, which I would expect to be the intended behavior of sync.

It is ok for you personally and your project. But it may be not ok for everyone who uses sqlite_orm. That's why it couldn't be merged into sqlite_orm. But it can be stored in your fork and you can use your fork instead. Or just use drop_trigger as I said before. Of let's find a way how to compare trigger's state and drop it only when it really differs