You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been manually testing the front end of my Rails 6.1 API application after upgrading from 5.2.8 earlier today. All my rspec tests pass but I found a few weird things happening when actually using the site through the front end. As I was testing this stuff, I discovered that one of my counter caches for a has_many through: relationship wasn't working properly because I didn't set it up properly.
I changed the configuration in the appropriate model file and after adding a few new records, the counter cache started updating properly after adding additional new records, but it never took the existing records into account. When I went into the Rails console and ran the appropriate command to manually update the count, I just get this output:
irb(main):007:0> PlayedSong.counter_culture_fix_counts
Artist Load (15.7ms) SELECT "artists".id, "artists".id, COUNT("played_songs".id)*1 AS count, MAX("artists".played_songs_count) AS played_songs_count FROM "artists" LEFT JOIN "played_songs" AS played_songs ON "artists".id = played_songs.artist_id GROUP BY "artists"."id" ORDER BY "artists"."id" ASC LIMIT $1 [["LIMIT", 1000]]
Performance Load (6.7ms) SELECT "performances".id, "performances".id, COUNT("played_songs".id)*1 AS count, MAX("performances".played_songs_count) AS played_songs_count FROM "performances" LEFT JOIN "played_songs" AS played_songs ON "performances".id = played_songs.performance_id GROUP BY "performances"."id" ORDER BY "performances"."id" ASC LIMIT $1 [["LIMIT", 1000]]
Performance Load (0.8ms) SELECT "performances".id, "performances".id, COUNT("played_songs".id)*1 AS count, MAX("performances".played_songs_count) AS played_songs_count FROM "performances" LEFT JOIN "played_songs" AS played_songs ON "performances".id = played_songs.performance_id WHERE "performances"."id" > $1 GROUP BY "performances"."id" ORDER BY "performances"."id" ASC LIMIT $2 [["id", 1000], ["LIMIT", 1000]]
Song Load (5.9ms) SELECT "songs".id, "songs".id, COUNT("played_songs".id)*1 AS count, MAX("songs".played_songs_count) AS played_songs_count FROM "songs" LEFT JOIN "played_songs" AS played_songs ON "songs".id = played_songs.song_id GROUP BY "songs"."id" ORDER BY "songs"."id" ASC LIMIT $1 [["LIMIT", 1000]]
=> []
So, using the above, it was the counter cache on both Tour and TourLeg that wasn't populating. Once I fixed those counter_culture lines to use the array format, new performances added started updating the appropriate PlayedSong counter caches expected.
I tried running the counter_culture_fix_counts command for all the models/associations I'm using counter_culture on and it's the same behavior for each. Finishes almost instantly and just has an empty array for output with similar SQL output. If I wipe out my development database and re-import from production, everything works great (I made a migration that contains the all the necessary Model.counter_culture_fix_counts which runs after the counter fields are added to each model).
It says right in the description of the gem that you run these manual functions weekly so I assume it works, but I can't seem to figure out how to get it to work. I've scoured the documentation and the issues so if I'm missing something obvious, I apologize. And the most advanced functionality I'm using with counter_culture counter caches is handling a couple HMT relationships.
Is there something more I need to do to get counter_culture_fix_counts to work after it's already been run on the database initially? I figured new records would allow it to see something was up, but no. Same with adjusting the hierarchy on the HMT relationships.
The text was updated successfully, but these errors were encountered:
I've been manually testing the front end of my Rails 6.1 API application after upgrading from 5.2.8 earlier today. All my rspec tests pass but I found a few weird things happening when actually using the site through the front end. As I was testing this stuff, I discovered that one of my counter caches for a has_many through: relationship wasn't working properly because I didn't set it up properly.
I changed the configuration in the appropriate model file and after adding a few new records, the counter cache started updating properly after adding additional new records, but it never took the existing records into account. When I went into the Rails console and ran the appropriate command to manually update the count, I just get this output:
And here's the PlayedSong model's relevant code:
So, using the above, it was the counter cache on both Tour and TourLeg that wasn't populating. Once I fixed those counter_culture lines to use the array format, new performances added started updating the appropriate PlayedSong counter caches expected.
I tried running the
counter_culture_fix_counts
command for all the models/associations I'm using counter_culture on and it's the same behavior for each. Finishes almost instantly and just has an empty array for output with similar SQL output. If I wipe out my development database and re-import from production, everything works great (I made a migration that contains the all the necessary Model.counter_culture_fix_counts which runs after the counter fields are added to each model).It says right in the description of the gem that you run these manual functions weekly so I assume it works, but I can't seem to figure out how to get it to work. I've scoured the documentation and the issues so if I'm missing something obvious, I apologize. And the most advanced functionality I'm using with counter_culture counter caches is handling a couple HMT relationships.
Is there something more I need to do to get
counter_culture_fix_counts
to work after it's already been run on the database initially? I figured new records would allow it to see something was up, but no. Same with adjusting the hierarchy on the HMT relationships.The text was updated successfully, but these errors were encountered: