CrolishGrandma

  • 1 Post
  • 4 Comments
Joined 1 year ago
cake
Cake day: June 30th, 2023

help-circle
  • It should work that way. If you use the recommended Docker Compose scripts for immich, you’ll notice that only a few volumes are mounted to store your data. These volumes don’t include information about running instances. If you take snapshots of these volumes, back them up, remove the containers and volumes, then restore the data and rerun the Compose scripts, you should be right where you left off, without any remnants from previous processes. That’s a pro of container process isolation


  • Your description of the problem makes sense. If you think improving the user experience in this way is worthwhile, then go for it. Just remember, most users don’t pay attention to the address bar.

    For implementation, I suggest creating a new table, something like ‘tb_user_category_index,’ with userId as a foreign key and an integer that increments each time it’s used. Automating this process in the database would be ideal: set it up once and let it run on its own, keeping things simple.

    However, don’t confuse this cosmetic index with a primary key. The primary key should only serve as a unique identifier for a record and hold no other information.



  • You are correct. Its quiet a find but I can reproduce this. I suspect the issue lies in the piece of code that tries to make sure you don’t get the same animal twice when you select a random animal. You can also follow the steps until there is only the Newt and then press the dice below it’s name. Now there are no animals.

    The random selector subtracts one from the total options and adds that one back if the new number is greater or equal to the precious number. So in case of only a single option it gets 0 at random, which equals the previous index and does +1, which doesn’t exist.

    There should be a failsafe that prevents this logic if there is only one animal in total 🤷‍♂