[Bug] Crash on initial startup leads to incomplete exercise DB

[JonathanGuberman]

Because of a separate problem (#44) I tried deleting and reinstalling the app fresh; during the initial startup when the exercise DB was being populated the app crashed, leading to an incomplete exercise DB when running it subsequently.

[JonathanGuberman]

For what it's worth, I've tried deleting and reinstalling, but I haven't been able to reproduce this crash.

[cfilipov]

Hey just wanted to let you know, I haven't abandoned this project despite the lack of updates over the last few weeks. In addition to my actual job and family stuff I've been busy, yak shaving.

I think it's worth it though. The author of SQLite.swift claims to be working on support for Swift 3.0, but is doing it privately so I don't know how far along it is. Swift 3 is a big deal because it's a huge change to the language, but also the foundation libs in Swift 3 also bring with it some stuff I would have implemented manually (things like #36).

GRDB (the SQLite lib I am transitioning to) already has a Swift 3 branch, and I've loved the API of GRDB and the thread handling, and everything about it. The code I've migrated to GRDB is already more readable and easier to work on. I plan to fix the bugs you brought up and a few minor things on the current code base but I am holding off on the rest of the issues until Swift 3.

[JonathanGuberman]

No worries, I have no expectations of constant support on a single-developer alpha-/beta-stage side-loaded open-source project. I just hope that whenever the bugs are fixed there's a way. for me to import all my old data, and enter in all the data from the workouts I'm currently missing! 😄

[cfilipov]

Because of a separate problem (#44) I tried deleting and reinstalling the app fresh; during the initial startup when the exercise DB was being populated the app crashed, leading to an incomplete exercise DB when running it subsequently.

Strange that this would happen. The whole initial setup and db migrations should all be happening inside a SQL transaction. If something fails it should be all or nothing.

That said, the crash that happened here was likely the same one from #44 since the same code gets ran during migration (recalculating workouts).

I just hope that whenever the bugs are fixed there's a way. for me to import all my old data, and enter in all the data from the workouts I'm currently missing!

I assume you have been logging your data outside the app manually somewhere and that you have at least one backup of your data. First of all, if you have a backup of the db that caused the app to crash (before getting it into that inconsistent state), you can try to start from that backup and it should no longer crash in 0.1.1. If not, then start from your last known good backup. You can manually add your data to the SQLite DB using one of the free SQLite tools (you only need to add to the workset table), this can be error prone but it's probably faster. A slower but safer/easier option would be to use the app to enter each set that you have been recording manually since the app stopped working. Do this sequentially because the app still doesn't support inserting past data, only adding new data. You can now enter the duration manually so this is now possible. If you choose to do it manually in SQLite DB directly, you will need to use the "rebuild all workouts" function found in the debug settings (do a backup first!).

[cfilipov]

Actually, I'm going to leave this open to remind me to make sure this is actually done in a transaction. A crash here should not corrupt the db.

[JonathanGuberman]

My backup DB opens without any issues in 0.1.1.

As for adding the data manually, it has to be done through the DB rather than the app, because, while the app now lets you select the date and time, it does not save these values; no matter what they are manually set to, it switches them to the current date and time. This is true for entering and for editing existing data points.

For manually editing the DB, you must be sure to put a value into all the relevant fields, even the calculated ones; though the will get recalculated later, the app crashes (similar to #44) if they are left out. Also, it isn't sufficient to add the workset table, because a workout entry does not seem to be manually created when using "recalculate all workouts", so you must manually create that as well (similarly, the numbers will be replaced with the correct ones when recalculating). Exercise names are not replaced when recalculating, so whatever text you enter will stick around there, although that doesn't seem to cause any ill effects.

[cfilipov]

Thanks for the detailed info. This should all get much simpler in the next version where I take everything I learned about the current design and hopefully improve it. The calculated fields are annoying but necessary otherwise some daily queries will be unacceptably slow. However, the calculated fields also make everything a lot uglier.

As for adding the data manually, it has to be done through the DB rather than the app, because, while the app now lets you select the date and time, it does not save these values; no matter what they are manually set to, it switches them to the current date and time. This is true for entering and for editing existing data points.

Dammit. This is the part I didn't test thoroughly, so of course I shouldn't be surprised it didn't wotk as expected. I think this should be easy enough to fix in the current code base rather than delay until the GRDB migration.

For manually editing the DB, you must be sure to put a value into all the relevant fields, even the calculated ones; though the will get recalculated later, the app crashes (similar to #44) if they are left out.

As expected. The app will always generate the calculated fields on input so it expects them to be there when querying, otherwise it fails hard to signal programmer error. This can be handled more gracefully, but in the future I hope to avoid the situation all together.

Also, it isn't sufficient to add the workset table, because a workout entry does not seem to be manually created when using "recalculate all workouts", so you must manually create that as well (similarly, the numbers will be replaced with the correct ones when recalculating).

I'm [somewhat] surprised by this, it should get generated, I'll look into it when I get a chance.

Exercise names are not replaced when recalculating, so whatever text you enter will stick around there, although that doesn't seem to cause any ill effects.

This is intentional and an artifact of how I planned to handle the now inoperable CSV import functionality. I assumed CSV would not contain exercise IDs (or that the IDs would be meaningless outside the scope of the DB) so I was using the name and fuzzy matching to figure out the exercise ID. This turned out to really suck, but anyway the point of that name field was to preserve the original name that was imported from the CSV in case (inevitably) the fuzzy match guessed incorrectly. I've since reconsidered how CSV import should work. Now I am going to go with a simpler approach. Leave it up to the user to manually figure out exercise IDs for now and expect the CSV file to specify them. Of course there are things that can be done in the app to make importing easier but the development time to implement that vs just doing some search and replace in excel makes me think it's not worth it.