I am looking at ways to migrate a SQLite DB in an android app to Realm. The DB has about 2000 records that need to be inserted upon first load. Is there a way to do this using the migration mechanism (https://realm.io/docs/java/latest/#migrations) and createOrUpdateAllFromJson()?
Migrations are not really used to insert data on first load. RealmConfiguration has a method called initialData() that is much more suited for this: https://realm.io/docs/java/latest/api/io/realm/RealmConfiguration.Builder.html#initialData-io.realm.Realm.Transaction-
createOrUpdateAllFromJson() only makes sense if you can export you SQLite database to JSON. Most likely it will be much faster to just read the data directly from SQLite and insert them into Realm.
A more type-safe method would be to use copyToRealmOrUpdate() if you can somehow export your SQLite data to a in-memory object representation.
Related
I’m new to Android development and I’m about to implement simple Preferences for my app. It appears SharedPreferences is a dead end and has lots of warts, so I’m looking at DataStore (non-Proto) vs Room. Since I ALREADY heavily use Room and LiveData (yes, I know Flow is the new hotness) in my app for other things, is there any benefit to using DataStore too? I understand Room is recommended for large or complex data as I’ve already reviewed the following, but I’m hoping a more seasoned developer can further hit this home for me:
https://android-developers.googleblog.com/2020/09/prefer-storing-data-with-jetpack.html
https://proandroiddev.com/lets-explore-jetpack-datastore-in-android-621f3564b57
https://medium.com/better-programming/jetpack-datastore-improved-data-storage-system-adec129b6e48
Thank you.
The official blog post you linked has a section specifically about Room vs DataStore:
If you have a need for partial updates, referential integrity, or support for large/complex datasets, you should consider using Room instead of DataStore. DataStore is ideal for small , simple datasets and does not support partial updates or referential integrity.
User preferences almost always fall into the 'small, simple datasets' that can be easily expressed as key/value pairs (or something more complicated if you want to use the Proto DataStore) that do not need the overhead of a table schema, SQL queries, custom parsing, or the 'relational' part of a relational database.
The problem with datastore is you cannot just fetch or update a part of data from a list like you can with SQLite libraries such as Room. This is true for both Proto and Preferences version. So if you have 10 thousand elements and you save them to DataStore and then you want to update 2 of them based on a condition you'll have to fetch the entire list, manipulate it and put it back. Here Room (or any DB solution) will be a way to go
But if you just want to save user preferences or small data it would be an overkill to use a DataBase - here DataBase Proto will actually be the perfect choice
I've been implementing SQLite data storage for my Android translator app.
The situation is: the app receives traslation as a JSON from server, parses it and builds an object tree (50 to 100 objects in average);
Now I need to save it into SQLite DB. I've asked my teacher, and he recommended not to save the whole JSON response but to make a more complex DB structure.
I've done so, but I'm concerned for those 50-100 DB queries, which are done (and, respectively, 50-100 rows created) to save just one dictionary article.
Now I'm wondering what is the best way to store complex object tree in DB or if it is OK to do up to 100 DB queries.
Maybe, nevertheless, the better way is to store the JSON response in DB? The only operation over the dictionary articles I need is to search them, no modification is needed.
It is better to have a proper database structure and normalised data. This will allow you to query your data more efficiently. Also, it will be much easier to understand for other people if they ever develop your code.
You should do all your updates in one transaction and you will be fine with saving 100 records in one go. You can use a structure similar to that one:
SQLiteDatabase db = sqlHelper.getWritableDatabase(); // this returns a database
db.beginTransaction();
try {
// all your updates
db.setTransactionSuccessful();
} finally {
db.endTransaction();
}
db.close();
If you use transactions properly, you'll be fine. Do all the writes within a single transaction and commit the transaction when complete.
The question is : When does GreenDao update the sql database from the session cache?
Let say that I'm querying an existing entity out of the database and than change one of it properties(fields). The changes are performed without directing the sql database in anyway.
So - should I do update on the entity?
When does GreenDao flush it's session cache into the database itself?
What you describe sounds like JPA/Hibernate session cache. greenDAO doesn't have that. It is simpler. There are objects kept in memory and you always update them manually to the database.
Some more information (far from complete):
http://greendao-orm.com/documentation/sessions/
When one generates the GreenDAO code (Entities, DAOs, DaoSession....etc), the DAOs by default extend the AbstractDao class which has a variety of methods for updating the database when needed instead of keeping the update in memory for a while such as (update(T entity), refresh(T entity), updateInTrx(java.lang.Iterable entities)).
For more information check the AbstractDao javaDoc
I am building an application which has a database with two tables created internally using SQLiteOpenHelper.When ever the application is running,it receives some data and saves it into the tables.What I want is to clear the data tables when ever the application is started?
I looked into this post How can I clear an SQLite database each time I start my application? which is not clear of how to use application.
SQLiteOpenHelper has the ability of creating in-memory databases if you pass the constructor a null name. Probably this is what you are looking for.
For example:
SQLiteOpenHelper sqloh = new SQLiteOpenHelper(context, null, null, 1);
SQLiteDatabase sqldb = sqloh.getWritableDatabase();
will create an in-memory db.
SqliteDatabase uses the method openOrCreate(...) which opens a database if it exist and creates and opens it when it doesn't exist. see docs based on that you could just delete the database file that is created before you do any database calls so that a new one is created each time.
This SO question gives the location of the file: Location of sqlite database on the device
There other route would be just to delete the data in the tables when the application starts by executing a sqlite query:
DELETE FROM your_table
My only thought would be do you really need a database if you are going to delete it every time the application starts. If you are not updating the data then why not just "cache" a json file with the data. The GSON library is awesome for taking json and converting it to java object with very little code, going to be less code than working with sqlite. But the recommendation comes from not having the big picture for what you are trying to accomplish. You then would just delete the json file(s) when the app starts instead of the db file.
How can I insert a list of data into SQLite which is fetched from a remote database? Also I want to list out these data during offline mode. What is the easiest method to do this?
You can create a ContentProvider (in most cases it ends up necessary)
http://developer.android.com/guide/topics/providers/content-provider-basics.html
Or use the SQLiteDatabase and SQLiteOpenHelper classes:
http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html
http://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html
Or the ORMLite library:
http://ormlite.com/sqlite_java_android_orm.shtml
the best way is, i have the same thing as you. from an api i will get thousands of xml and need it to store in 3 tables of a database. it will happen when i launch the app. for the best practice i will do the fetching data from api and storing it in 3 tables in Async Task as follows:
do in background(){
do your fetching data from remote
store in db.
}