Fixed
Status Update
Comments
ga...@gmail.com <ga...@gmail.com> #2
Thanks for the thorough report - you're right about the problem, and the workaround looks good - it even handles the fast cases for initialization and setList(null) nicely.
Fix and tests submitted internally, should go out with next paging release.
Fix and tests submitted internally, should go out with next paging release.
yb...@google.com <yb...@google.com> #3
Actually, I'd like to know more about what failed here and why.
I'm curious if InstantTaskExecutorRule is putting paging into an unexpected state - do you have a sample project that reproduces the issue?
When hitting this outside of a test, are you specifying any custom executors, possibly ones which run main thread tasks immediately instead of posting them?
I'm curious if InstantTaskExecutorRule is putting paging into an unexpected state - do you have a sample project that reproduces the issue?
When hitting this outside of a test, are you specifying any custom executors, possibly ones which run main thread tasks immediately instead of posting them?
Description
Migration fails only because old database was created with type "integer", while Room by default expects "INTEGER". Take a look at picture also.
I'm 100% sure this is the problem, because if I change old DB datatypes to capped letters during migration (with that being the only change), Room picks it up properly.
Component used: Room
Version used: 1.0.0-alpha3
Devices/Android versions reproduced on: Motorola Moto G (Android 5.1)
- Screenshot attached