Closed DeeDeeG closed 5 years ago
I'm also unsure if we should even be grouping by edit_id
.
I think that value should always be unique, and we should group by id
instead?
If I understand it correctly:
id
and edit_id
matchid
but a fresh edit_id
Thus no two entries have a shared edit_id
, and grouping by id
produces only the freshest edit of a given restroom entry.
Might be wrong about this, would love some comment from @mi-wood and/or @stardust66.
From the way I understand the editing process, when an edit is submitted, a new restroom entry is made with a new id
and an edit_id
matching the id
of the original restroom. Thus, grouping by edit_id
ensures that the newest restroom, which is the one with the highest id
, gets displayed.
I'm taking a look at db/export.csv
and the problem seems to be that there's no edit_id
in the csv at all. I think I'll just change db/seeds.rb
so that it adds edit_id
s to each restroom entry when loading the csv.
~We could also manually edit export.csv
instead, since it's only 21 entries long. I'd be able to do that without it taking too long.~
Edit: Whoops, I guess not. There are no field names in the db/export.csv
, only values. So the id
must be getting set implicitly, in order, based on which entry is created first (id => 1), second (id => 2).
I have a branch where I seem to have fixed this: https://github.com/DeeDeeG/refugerestrooms/commit/27d3e156adec45d2877ada5e9122736596072d81
Based on this stackoverflow answer: https://stackoverflow.com/a/12408934
Scope / difficulty of fixing this
Not too hard I hope?
Impact
Only affects local testing (in Docker, Vagrant, etc.) with the
db/export.csv
data. Fixing this will make the data fromdb/export.csv
behave properly alongside the new user edit proposals system._This has no bearing on our production instance, because the data there all have proper
edit_id
values._Problem
Data in
db/export.csv
have no actualedit_id
values to begin with.Rather than being migrated (or otherwise automatically processed) to have an
edit_id
matching theirid
, they all end up havingedit_id: 0
.Since we now group API results by
edit_id
and only display one result peredit_id
, the app only ever displays at most one result regardless of the specifics of the API call. (This will tend to be the Dolores Park Cafe entry, since it has the highestid
value).(From the documentary about software development, Highlander: "There can be only one!")
How to reproduce the problem
Proposed solution to this bug
Process the
db/export.csv
data in some way (a migration? somewhere else in our Ruby code?) so they haveedit_id
values matching theirid
values.