Status Update
Comments
ra...@google.com <ra...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
vi...@gmail.com <vi...@gmail.com> #3
vi...@gmail.com <vi...@gmail.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically ( b/140759491 ).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
https://android-review.googlesource.com/1288456
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
su...@google.com <su...@google.com> #5
Double-scheduling on API 23 is expected; we're doing this to work around a bug. We'll take a look at your exact issue though.
ra...@google.com <ra...@google.com> #6
This is expected. We migrated your JobScheduler jobs in alpha04. This caused all your old jobs (In JobScheduler) to get cancelled, and rescheduled to create new replacements.
We are the source of truth for Workers, so this is not a problem. Your jobs will still run ~once every 24 hours.
On API 23, we double scheduler Workers to work around an issue in JobScheduler. There will be cases where you will see 2 jobs, but we will internally de-dupe them and only 1 will every execute.
This is also expected.
Is there something else which is unexpected that's going on ?
We are the source of truth for Workers, so this is not a problem. Your jobs will still run ~once every 24 hours.
On API 23, we double scheduler Workers to work around an issue in JobScheduler. There will be cases where you will see 2 jobs, but we will internally de-dupe them and only 1 will every execute.
This is also expected.
Is there something else which is unexpected that's going on ?
vi...@gmail.com <vi...@gmail.com> #7
Yes, I noted two issues in API 23:
1. doWork() method call instantly after creating new PeriodicWorkRequest.
2. doWork() method call if I restart the device and open my application from device menu again.
In API <23 and >23 it is not calling doWork() method in above scenario. doWork() executes only after the time mentioned in PeriodicWorkRequest and working fine as expected.
You can refer GitHub code:https://github.com/patelviraj/WorkManagerDayCounter for a better idea.
1. doWork() method call instantly after creating new PeriodicWorkRequest.
2. doWork() method call if I restart the device and open my application from device menu again.
In API <23 and >23 it is not calling doWork() method in above scenario. doWork() executes only after the time mentioned in PeriodicWorkRequest and working fine as expected.
You can refer GitHub code:
ni...@gmail.com <ni...@gmail.com> #8
I got also an issue in alpha04 with PeriodicTask, I schedule PeriodicTask1 which should execute once a day with internet constraint.
The app contains a button which will try to schedule PeriodicTask2, which should execute once a day with internet constraint. I check if already schedule and if it does I do nothing.
Well this seems to "wakeup" the workmanager and it start PeriodicTask1 everytime. I'll do a sample and send it in another bug issue.
The app contains a button which will try to schedule PeriodicTask2, which should execute once a day with internet constraint. I check if already schedule and if it does I do nothing.
Well this seems to "wakeup" the workmanager and it start PeriodicTask1 everytime. I'll do a sample and send it in another bug issue.
su...@google.com <su...@google.com> #9
Re: #8, could you please file a separate bug so we can look at your exact issue?
ra...@google.com <ra...@google.com> #10
I just tried creating PeriodicWorkRequests on API 22, 27 & 28.
On all API levels the first instance of the PeriodicWorkRequest runs immediately. The second instance of them runs per schedule.
For (2): doWork() will be called when you do a reboot, as upon reboot Jobs are rescheduled.
So this is also WAI.
If you would like to provide us with more info, then I can reopen this bug.
On all API levels the first instance of the PeriodicWorkRequest runs immediately. The second instance of them runs per schedule.
For (2): doWork() will be called when you do a reboot, as upon reboot Jobs are rescheduled.
So this is also WAI.
If you would like to provide us with more info, then I can reopen this bug.
ra...@google.com <ra...@google.com> #11
I also checked API 23.
vi...@gmail.com <vi...@gmail.com> #12
Please find additional info as follow:
I have attached two images of Logcat which I get in API 26 and API 23.
doWork() code in file DayIncrementWorker.java:https://drive.google.com/file/d/1K5A97BLp4gZPUY1ZursE3xwKiSSFt8mD/view
PeriodicWorkRequest code in DayIncrementViewModel.java:https://drive.google.com/file/d/13u2RgoZZ8aOU_D7us0F4NEntespwcm0V/view
Full Source Code:https://drive.google.com/drive/folders/1Vy1tIUbKtp2AhDd6j8uJD89R__QMaEa6
The problem occurs only in API 23. In rest of the API levels, it is working fine.
I have attached two images of Logcat which I get in API 26 and API 23.
doWork() code in file DayIncrementWorker.java:
PeriodicWorkRequest code in DayIncrementViewModel.java:
Full Source Code:
The problem occurs only in API 23. In rest of the API levels, it is working fine.
ni...@gmail.com <ni...@gmail.com> #13
#9 / su , I found that my issue is linked to https://issuetracker.google.com/issues/111195153
It seems that if we have a periodicworker scheduled, scheduling another worker (a onetime this time) will run the periodicworker each time.
I have a button that schedule a onetimeworker, and by debugging I saw that the getEligibleWorkForScheduling in the schedule method of Schedulers class will return my periodic worker, then be called again, this time it return the onetime worker, and then the last time it returns an empty list.
It seems that if we have a periodicworker scheduled, scheduling another worker (a onetime this time) will run the periodicworker each time.
I have a button that schedule a onetimeworker, and by debugging I saw that the getEligibleWorkForScheduling in the schedule method of Schedulers class will return my periodic worker, then be called again, this time it return the onetime worker, and then the last time it returns an empty list.
Description
Version used: 1.0.0-alpha03
Devices/Android versions reproduced on: API 23 (Emulator as well as Real Device)
- Screen recording is attached here
Also, I have created a demo project on GitHub:
The issue is also reported here: