QA » openQA Project

That reminds me another partially related task we have always wanted to perform, remove so many foreign key and use strings instead of state_id and result_id. Maybe I'll take the opportunity.

really? I thought foreign keys to 4 rows tables are a fetish of Ludwig. It would make the code so much easier if result was an enum instead of an id

If I remember correctly, they were a fetish of Alberto. As far as I remember, Ludwig didn't have a strong opinion on that regard.

Initial switch was smooth except for the timestamp triggers. They are driving me completely nuts. The mechanisms for triggers are different in each database system. For example, in PostgreSQL you need to define a PL/SQL function, which means having a special privilege in the database and dealing with SQL::Translator::Schema::Procedure in order to make everything work with our migrations (I have not managed to succeed yet after a whole afternoon.

From the very beginning I suggested to use https://metacpan.org/pod/DBIx::Class::TimeStamp instead of adding the triggers because I was afraid if hitting exactly this situation. I would like to play my I-told-you card here (as with state_id and result_id) and take the opportunity of the migration to change some database-related things. That is, switching to Class::Timestamp instead of triggers and to label instead of foreign keys for the states and results.

Anybody against it?

I'm not. As expressed in the call, I have very little patience with the timestamps anyway.

Not closing because the packaging tasks are still pending (there are new dependencies and a new configuration file) and I expect some bugs to arise.

I finally didn't remove states and results tables because it was not needed. I still want to do it but I'll add a separate issue in progress for it.

Maybe dump_templates and load_templates can be extended to migrate everything to a new engine without wiping the existent data out. Should we consider it part of this issue or create a new one?

Some time spent researching to create a tool to migrate between engines. Not feasible. Instead I have almost-working SQL scripts to dump sqlite and to populate postgresql with the resulting data.

Finished the sql scripts to dump the SQLite db (http://paste.opensuse.org/18660049) and restore the info in a PostgreSQL db (http://paste.opensuse.org/99854883)