BUG 518 AP@10 change was not actually merged

[david-fisher]

#535 purported to fix #518 that #519 was also supposed to have fixed. MR 519 had the change to db/scorers/[email protected] that is now missing from the current master.

[david-fisher]

Or rather, while merged, the deployed quepid still displays the old version (not installed into the DB on deployment?)

see http://app.quepid.com/scorers

[epugh]

Well... Hell.....

[epugh]

Can you open up a FRESH pr... And we'll track the steps of merging it, and confirming that deploys pick up this new change? I'm a bit nervous that the seed data "create or update" logic isn't working the way we want....

[david-fisher]

This needs investigation, the ap10.js file is in the correct place, so it is the DB update process on deploy that likely has the issue.

[david-fisher]

It looks like the use of first_or_create when loading the scorers (db/seeds.rb) is not updating the older version. In the migrate subdirectory, there is 20201203212611_bugfix_ap_ndcg_scorers.rb that performed a manual update of the DB for some earlier issue. Ruby is not my forte, but I think there needs to either be one of these scripts run to force the update, or the first_or_create should be changed to some form of update. It is not clear to me if this is actually where the DB update comes from, but I think that it is.

[david-fisher]

Tried creating a migration, first step was successful, empty migration file created. Added the necessary code. Second step failed with:
dfisher@OSC-Consult quepid % bin/docker r bundle exec rake db:migrate [+] Running 5/5 ⠿ keycloak Pulled 15.3s ⠿ cee3a6bad5fa Pull complete 2.5s ⠿ a96f279ebd65 Pull complete 2.5s ⠿ 0123b54baa91 Pull complete 11.0s ⠿ 8844b89352aa Pull complete 12.5s [+] Running 3/3 ⠿ Container quepid_db Running 0.0s ⠿ Container quepid_keycloak Recreated 1.6s ⠿ Container quepid_redis Recreated 0.5s [+] Running 2/2 ⠿ Container quepid_keycloak Started 0.4s ⠿ Container quepid_redis Started 0.3s Your Ruby version is 2.7.4, but your Gemfile specified 3.1.2

Creating a pull request for the migration file, but not clear how to run it in production.

[david-fisher]

Build fails:
You have 1 pending migration:
20230117150814 FixAp
Run bin/rails db:migrate to update your database then try again.

Have to solve the migrate problem first, apparently.

[david-fisher]

Trying to update the ruby version has not resolved the situation. No amount of updating/installing gets past this error:
dfisher@OSC-Consult quepid % bin/docker r bundle exec rake db:migrate
[+] Running 3/0
⠿ Container quepid_keycloak Running 0.0s
⠿ Container quepid_db Running 0.0s
⠿ Container quepid_redis Running 0.0s
Could not find concurrent-ruby-1.1.10 in any of the sources
Run bundle install to install missing gems.
Even though said concurrent-ruby-1.1.10 did install.

Fetching source index from https://rubygems.org/
Resolving dependencies......................................................................................................
Using rake 13.0.6
Fetching concurrent-ruby 1.1.10
Installing concurrent-ruby 1.1.10

After much gymnastics, mysql and concurrent ruby installed. The migration code needs a guard against nil value, as there are no scores in the DB that is in the docker container.

This is now beyond my ability to diagnose. The migration file to update the db is in the branch, fix-ap. That branch currently fails it's circle-ci due to the unmigrated migration.

I am not convinced that this migration is actually a fix for the unupdated DB in production.

[david-fisher]

Deleting the entire quepid source tree, recloning, and building from scratch enabled running the migration.

[epugh]

So... We may have a conceptual problem in how db:seeds work.... This command is what actually seeds the database, and it is run by setup_docker.. https://github.com/o19s/quepid/blob/main/bin/setup_docker#L40

I need to find out if changing and loading seed data for an already deployed app is considered good practice, or if seeds are really meant to seed a new setup... And for an existing setup, then migrations are the way to go.... Asking my local Ruby community for input ;-)

[epugh]

I have reached out to my community of experts on this... and will follow up tomorrow ;-)

[epugh]

The brain trust agrees, db:migrate is the way to go......

[epugh]

➜  quepid git:(blah) heroku run bin/rake db:migrate -a quepid-staging
Running bin/rake db:migrate on ⬢ quepid-staging... up, run.1323 (Basic)
/app/config/initializers/sidekiq.rb:6: warning: Sidekiq's Delayed Extensions will be removed in Sidekiq 7.0
I, [2023-01-18T18:47:58.999749 #4]  INFO -- : Migrating to FixAp (20230117150814)
== 20230117150814 FixAp: migrating ============================================
== 20230117150814 FixAp: migrated (0.0829s) ===================================

[epugh]

and in produciton!