Sample Data polluting new instances

[Tyler-Angell]

OS & Hardware

cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

cat /proc/cpuinfo | grep 'Model'
Model		: Raspberry Pi 4 Model B Rev 1.4

Version 0.25.3

Describe the bug When deploying a new instance of Dawarich sample data is provided to show how to use the project. This is interesting, but not when I want to track my own data. You may consider multiple bugs in the repro steps, but

To Reproduce Steps to reproduce the behavior:

1. Copy docker-compose.yml following instructions on the intro page.
2. Modify postgis/postgis:14-3.5-alpine to imresamu/postgis:14-3.5-alpine since postgis doesn't publish linux/arm64/v8 containers as identified in the moving to postgis page
3. Run docker compose up -d
4. Navigate to http://<host>:3000
5. Login with [email protected] and password as identified in the intro page
6. Observe DELETE_ME_this_is_a_demo_import_DELETE_ME data populated on 2024-10-12
7. Delete 644 points 50 at a time to clean up account
8. Observe stats page still contains distance in October 2024 and lifetime stats
9. Click various Update buttons
10. Observe no update or clearing of data
11. Discover ability to add new user from the Demo User's settings tab
12. Add new user thinking it will be a fresh instance
13. Log in as the new user
14. Observe the 644 data points have also been imported.

Expected behavior I expect the ability to start off with a clean instance so that I may track my data and not have the stats thrown off by the initial sample data from a year before I even began to use the product.

Screenshots Image after the points had been deleted and still showing the stats from the sample data. No change with Uupdate or Update stats.

Logs Logs are currently full of yelling at me about Prometheus connection refused, will dig into that later.

Additional context My suspicion is the below chunk of code is responsible. In the docs I have not found an exhaustive list of environments and what their distinction is, but the dockerfile we're instructed to use is set to development, and all the generic environment names include the sample data by default, with the exception of the ability to turn it off in test. Though I dont know what else in in scope of that environment and have yet to try it.

return unless Rails.env.development? ||
      Rails.env.production? ||
      (Rails.env.test? && ENV['IMPORT_SAMPLE_POINTS'])

Suggestion: Make the return unless only consider the IMPORT_SAMPLE_POINTS environment variable and document it/include it in the docker-compose.yml.

Request: Only populate the sample data in the demo user's instance and have new users start with a fresh instance.

[Freika]

The idea is for each user to have a hint on how to use Dawarich, but you're right about stats, they should be removable

[SisyphusMD]

I’m running into this same issue. Would be okay if deleting the import also cleared the distance travelled for October 2024, but deleting the points does not delete the stats. I tried creating a user after deleting the sample gpx file, but that unfortunately breaks it as well.

[Freika]

In the console, you can find and delete stats:

user = User.find_by(email: "your@email")
stat = user.stats.find_by(year: 2022, month: 9)
stat.destroy

[Tyler-Angell]

Thank you @Freika for the cleanup commands. Other than the FAQ sharing that console is possible, are the console commands documented anywhere?

Also slight note to others who come across this in the future, for some reason the command setting the stat doesn't like having a space after the equals sign.

Fails

[12] pry(main)> user = User.find_by(email: "[email protected]")
  User Load (1.4ms)  SELECT "users".* FROM "users" WHERE "users"."email" = $1 LIMIT $2  [["email", "[email protected]"], ["LIMIT", 1]]
=> #<User id: 1, email: "[email protected]", created_at: "2025-04-04 23:20:19.459219000 -0700", updated_at: "2025-04-04 23:21:38.832401000 -0700", api_key: [FILTERED], theme: "dark", settings: {"fog_of_war_meters" => "100", "meters_between_routes" => "1000", "minutes_between_routes" => "60"}, admin: true, status: "active">
[13] pry(main)> stat = user.stats.find_by(year:2024, month:10)
Error: method '= user.stats.find_by(year:2024, month:10)' could not be found.

Succeeds

[14] pry(main)> user = User.find_by(email: "[email protected]")
  User Load (1.1ms)  SELECT "users".* FROM "users" WHERE "users"."email" = $1 LIMIT $2  [["email", "[email protected]"], ["LIMIT", 1]]
=> #<User id: 1, email: "[email protected]", created_at: "2025-04-04 23:20:19.459219000 -0700", updated_at: "2025-04-04 23:21:38.832401000 -0700", api_key: [FILTERED], theme: "dark", settings: {"fog_of_war_meters" => "100", "meters_between_routes" => "1000", "minutes_between_routes" => "60"}, admin: true, status: "active">
[16] pry(main)> stat=user.stats.find_by(year:2024, month:10)
  Stat Load (1.3ms)  SELECT "stats".* FROM "stats" WHERE "stats"."user_id" = $1 AND "stats"."year" = $2 AND "stats"."month" = $3 LIMIT $4  [["user_id", 1], ["year", 2024], ["month", 10], ["LIMIT", 1]]
=> #<Stat:0x0000007f91018360
 id: 1,
 year: 2024,
 month: 10,
 distance: 5,
 toponyms: [],
 created_at: "2025-04-04 23:21:59.790188000 -0700",
 updated_at: "2025-04-04 23:21:59.790188000 -0700",
 user_id: 1,
 daily_distance:
  [[1, 0], [2, 0], [3, 0], [4, 0], [5, 0], [6, 0], [7, 0], [8, 0], [9, 0], [10, 0], [11, 0], [12, 5.03], [13, 0], [14, 0], [15, 0], [16, 0], [17, 0], [18, 0], [19, 0], [20, 0], [21, 0], [22, 0], [23, 0], [24, 0], [25, 0], [26, 0], [27, 0], [28, 0], [29, 0], [30, 0], [31, 0]]>
[17] pry(main)> stat.destroy()
  TRANSACTION (0.4ms)  BEGIN
  Stat Destroy (2.0ms)  DELETE FROM "stats" WHERE "stats"."id" = $1  [["id", 1]]
  TRANSACTION (0.9ms)  COMMIT
=> #<Stat:0x0000007f91018360
 id: 1,
 year: 2024,
 month: 10,
 distance: 5,
 toponyms: [],
 created_at: "2025-04-04 23:21:59.790188000 -0700",
 updated_at: "2025-04-04 23:21:59.790188000 -0700",
 user_id: 1,
 daily_distance:
  [[1, 0], [2, 0], [3, 0], [4, 0], [5, 0], [6, 0], [7, 0], [8, 0], [9, 0], [10, 0], [11, 0], [12, 5.03], [13, 0], [14, 0], [15, 0], [16, 0], [17, 0], [18, 0], [19, 0], [20, 0], [21, 0], [22, 0], [23, 0], [24, 0], [25, 0], [26, 0], [27, 0], [28, 0], [29, 0], [30, 0], [31, 0]]>
[18] pry(main)> user.stats.find_by(year:2024, month:10)
  Stat Load (1.3ms)  SELECT "stats".* FROM "stats" WHERE "stats"."user_id" = $1 AND "stats"."year" = $2 AND "stats"."month" = $3 LIMIT $4  [["user_id", 1], ["year", 2024], ["month", 10], ["LIMIT", 1]]
=> nil

In summary, updated commands to prune stat sample data:

user = User.find_by(email: "your@email")
stat=user.stats.find_by(year: 2024, month: 10)
stat.destroy

[rouke-broersma]

Or just create a new user, make that one admin and then User.find_by(email: "[email protected]").destroy

[ssig33]

In the process of removing the sample data, I did get to learn a bit about the internals of this Rails app—but I assume that’s not the intended onboarding experience for most users.

The idea that “each user should have a hint on how to use Dawarich” might sound reasonable in theory, but when it comes to a timeline app, having fake activity logs inserted automatically is just frustrating. As a user, I never took those actions—so the sample data only polluted my own records and made things harder to clean up.

At the very least, I think we should avoid inserting sample data for users who are manually created through the settings interface. Wouldn’t that be a better default?

[Tyler-Angell]

Or just create a new user, make that one admin and then User.find_by(email: "[email protected]").destroy

@rouke-broersma - That is what this bug is. New users created are pre-populated with data from October 2024. I'm all for the [email protected] user having pre-populated data. But when I create a new user, that user, admin or otherwise, should be empty.

[rouke-broersma]

Or just create a new user, make that one admin and then User.find_by(email: "[email protected]").destroy

@rouke-broersma - That is what this bug is. New users created are pre-populated with data from October 2024. I'm all for the [email protected] user having pre-populated data. But when I create a new user, that user, admin or otherwise, should be empty.

Oh right, hadn't noticed that.. I also don't like pre-population of this demo user personally. Especially since you can't yet delete users from the ui.

[Freika]

Sample data is no longer being created starting ~ 0.26.0