Open dmrowietz opened 4 weeks ago
Not sure how that commit could cause this, if you could please upload more details to try and reproduce this bug.
Perhaps the readTable
method in drift isn't reliable on all devices?
ADB logs or flexify app db dump would be appreciated.
One important piece of information that I forgot to write yesterday: This bug only occurs in 1.1.87 and later. 1.1.86 works fine. That's why I am suspecting that particular commit in the first place.
I hope that was the missing piece for you to reproduce this. I not please let me know, I'll do my best to provide additional information.
I have dug a little deeper into this. To pinpoint the problem I did the following in a test environment:
In Branch https://github.com/dmrowietz/Flexify/tree/issue_123_debugging I removed all but one item from defaultExercises and defaultPlans to make the DB as simple as possible. I then built up the db-query step by step: a: join b: orderBy c: groupBy d: addColumns
Delete existing flexify.sqlite file <-- make sure this is the db of the test environment, not your actual database
Build flexify on the branch issue_123_debugging. I am building on Linux native, building for Android is broken for me at the moment.
Start app and add one set of "Arnold press" (1rep@1kg), restart the app
The DB is now very simple. It contains only one exercise with exactly one set with 1rep@1kg
Using a debugger take a look at the variables a,b,c,d in updateDefaults() => Curious, groupBy reduces the number of items. In my understanding it should not do that. More details: b._parsedData[1] is the set I created with 1rep@1kg Only _parsedData[0] gets past groupBy so i think this is where the problem lies.
When entering the page where the exercises are listed and sets can be input, the reps and weight are initially set to 0. Tapping on the exercise will update reps and weight to the correct numbers.
Steps to reproduce the behavior:
Expected behavior: reps and weight should be set to their proper values when first entering the page.
I am encountering the bug on Linux native in version 1.1.87. With version 1.1.86 I do not have this bug.
My guess: Has something to do with this commit