Instrumentation Testing Room migrations - android

We have a project that extensively uses offline storage hence Room. The database has been migrated so many times that It is currently on V77.
we are planning to incorporate migration testing now ( I know it is too late ) hence want to write test for migration fron v77 to v78.
I wanted to know what is the best way to write tests for this scenario , The database is huge and complex containing joins etc.
I tried following the articles on Room migration tests but it is only for a small schema.
Also the Room generated schema jsons have been limited , would that be an issue for this ? and is there a way to generate the previous versions like 1.json etc.
I have followed the online medium articles precisely like it has been implemented and has been getting errors when migration happens on database joins etc.
Then I tried to follow the Android Doc for testing migrations but since I dont have the json files for pervious versions , I cannot implement that.
Can anyone suggest a good repo or already implemented tests for a similiar use case
Thanks .

and is there a way to generate the previous versions like 1.json etc.
yes, you can change the code for the previous version(s) so that in the #Database annotation exportSchema = true is coded AND that the room.schemaLocation is set accordingly (and obviously that the version number is set accordingly). You can the compile the project and the schema for that version will be generated.
Obviously due to the above changes the version being compiled is not exactly the same. However, the schema should be exactly as required as long as no other changes have been made that affect the schema.

Related

Android/JVM SQLite database

I'm trying to have a small Android app have its own database, my first take on this was to simply use the Room persistence library, and it worked wonders, it's an awesome library but...
Later on I decided to try something weird and port that app to Desktop too (JVM).
My plan was to have 3 gradle modules:
common logic
android (importing common)
jvm (importing common)
Problem is that... I can't use Room anymore since it would be in the common logic module that's not an android module.
I tried to switch to Ktorm, and it seemed nice but Ktorm can't create tables from the schema so i had to drop it.
Then i tried to switch to Exposed since it has the functionality to create tables from the schema, but Exposed has a few problems:
The JDBC driver for Desktop (xerial) is not supported on android, so i should use different drivers per platform (for example using SQLDroid for android)
Its DAO can't have a table with a composite key (which i need to have), and not having the DAO would make everything harder in the code since I'd have to issue the queries directly and get a ResultRow, and then convert them to the objects I need.
My last resort would be creating some monstruous class that totally hide the database providing only the minimum read and write methods that i need and has some sort of flag called android and totally change what its methods do if that flag is true or false, so that it would use Room on Android and Exposed on JVM, but it sounds like a terrible idea.
Some idea of how would it be possible to create and use a simple SQLite database in both JVM and Android with the same code?
UPDATE:
I'm now using SQLDelight and even though it's not as comfy as Room and its documentation isn't super extensive, it's pretty nice and does what i wanted, figured out writing this could be useful for someone that come across my same doubt.

Android Room: Replace existing schema (migrations and all) with a new one?

I've been messing around with an Android project that uses a room database. Because I didn't design the database before I started (I didn't initially plan to even use one), it has a bunch of migrations that drop and recreate tables all over again.
I've never released the app since it's kind of a learning project, but if I ever show anyone I'd rather not show them the 3 migrations in a row where I drop and recreate the table. Is there a way just to tell it to use a completely new schema, as if it had never used one before?
Turns out I hadn't been wording my Google searches properly. I should have searched for how to reset to version 1 since that's a lot clearer than dropping tables or schemas.
See this stackoverflow link below to see what answered my question:
Room persistent library reset version to 1

Realm databases and compatibility between different schemas

I am creating Android app and need a way to store data and sync with server so i have posibility to have access to the same data from different devices and places. I am consider using Realm Database. I think that it will match all my requirements. But i have one question. Let assume that we released version 1.0 of our application, few users have access to one realm (lets name it REALM-ONE), they are making changes there(insert, update, delete). In meanwhile we developed a next version of our app with a little changed schema, i mean we add one property to the object and make a breaking changes in another(e.g. merge two properties into one and change data type). Part of the REALM-ONE users updated app to the newest version(other users cannot because of too old version of android), and i want everyone to have opportunity to still using the REALM-ONE as before without need to update app. Quick diagram:
According to docs i know what will happen with new property, it will update on server and be visible in v2.0 but surely should not be visible for previous version of the app. And what with breaking changes ? Can i support this change in v1.0 ? Can it still collaborate together ? Can I managed it with realm notifications or realm functions ?

DBFlow versus GreenDao orm library in Android

I am to pick a DAO library for an app that stores lot of data in SQLite tables with relations.
I first choose GreenDao, Since it is being used in many famous apps actively and is quite old, well tested and with bug fixed.
Where as DBFlow uses Annotation processing(Annotations are resolved at compile time, so compilation time will increase) And allows the user to decide the model cache, Sometimes proves faster than GreenDao(In some case only).
But DBFlow might not be having some bugs left or some scenarios uncovered since it is not being used actively in numerous apps like GreenDao is being used. (Sorry! I'm getting a bit Hypothetical).
"Which one is better from performance to code handling, DB migration and model alteration in future".
Have a look first:
GreenDao performance
DBFlow comparision with DBFLow
Guide me. Please.

Does greenDao support (or have plans to support) annotation processing?

I'm looking into greenDAO as an option for our database mapping needs. I noticed that greenDao does not use annotation processing, but instead uses a handmade java program to generate the source code.
Having just finished a small utility which uses annotation processing for generating code at compile time (to be used with Android ContentProviders), I wonder if greenDao ever considered using annotation processing and, if yes, why it was decided not to.
I would like to hook the code generation with the compile cycle of our Android projects and it would be nice if we could skip the extra step in creating the SourceGenerator project.
First of all, I'm not a member of greendao.
I'm just using it for some time now (and extended it to my needs). So some of my information is just a guess or my opinion.
I don't think greendao will support annotation-processing in near future, since there is nothing on their projects page.
Furthermore I think there are other features which seem more important.
For example:
Joins
ContentResolvers
extended code generators
On top of that I think database-structure shouldn't change as much as code does, so it is completely ok to have the code generation in a separate project, keeping the build-process of the app faster.
This may be a reason for not using annotations.
I'm using greendao for about 6 months now and I am at DB-Version 23. I am glad the generation didn't take place every time I built the project.
Greendao now supports annotation processing!
It is a feature in the latest major release (greenDao 3.0).
Check out the migration guide!

Categories

Resources