I have an Android app with a somewhat complex database (18 tables). The app currently uses OrmLite to map and manage database objects. I'd like to migrate the app incrementally to use Room. I've read about steps to migrate an existing SQLite app to Room, which involves replacing SQLiteOpenHelper with Room's SupportSQLiteOpenHelper. However, I don't think I could easily replace that within the OrmLite framework. Does anyone know if it's possible for OrmLite and Room to coexist in the same runtime, accessing the same SQLite database file? What steps would I need to take to ensure the database is not corrupted between the two frameworks, other than the obvious transfer of entity classes from OrmLite to Room?
Thank you.
Related
I am looking at migrating a native Android project from an SQLite database to an ORM. I have considered what I believe to be the fastest current contenders - DBFlow (based on SQLite) and Realm.
Therefore, out of curiosity, does anyone know what sort of data format Realm is using? Having read their documentation, this is seems to be a pretty closed subject and I could not find anything on the matter.
From their site - Realm is not an ORM on top of SQLite. Instead it uses its own persistence engine and their source code is open for java.
https://github.com/realm/realm-java
I want to integrate greenDAO – Android ORM for SQLite in my project. I am a bit of confused in between Schema and DaoMaster. Do I really need to create a Schema (creating new Module for creating Schema) beacuse what I understand the DaoMaster already implement the SQLiteOpenHelper class which is used to create table in Sqlite. Please explain the significance of creating Schema to integrate GreenDAO.
Everything you have to do its create DaoGenerator like here
http://greendao-orm.com/documentation/modelling-entities/ to generate all files you need.
The Schema is used to add the entities and generate automatically all the classes needed, like DaoMaster, DaoSession and the Dao and Object for each entity.
Technically, you should be able to use GreenDao without it, but It doesn't make sense for me, since one of the best things of GreenDao is this automatic generation.
Greendao doesn't use reflection to generate a mapping between your object model and your database-model by inspecting your entity-classes. Instead greendao hardcodes your mapping by generating your entity-classes, dao-classes and so on. This is what makes greendao faster than other ORM tools.
But somewhere you have to define your mapping and this is done by schema. To keep your app small the generation of the classes in done outside of your app, which means the logic to process any kind of schema and generate something out of it is not included in your app-code.
As #Jofre Mateu said it is technically possible to use greendao without generating schema, but it simply makes no sense: you'd throw away 99% of the features greendao offers and by implementing this yourself you'd introduce bugs into your app.
I am considering using ORMLite for persistance in an android app. A requirement is to be able to sync the underlying android SQlite database across multiple android devices.
Is this possible with ORMLite? And how?
You can directly copy the database file over to another device and it will work if you didn't change the schema.
I wouldn't recomment that though. Instead you could load the Object tree from your db using ORMLite, copy it over, and write it back to the db with ORMLite. You might want to look into SyncAdapters too.
Why we use ORMLite, if we already have Sqlite in Android ?
Is there any specific reason behind the ORMLite to use over SQLite in Android?
ORMLite is an open source software framework that provides lightweight object relational mapping (ORM) between Java classes and SQL databases.
ORMLite has two .jar files : ormlite-core.jar (275KB) and ormlite-android (50KB) libraries
Pros :-
1.)use for complicated database operations
2.)no need to remember to SQL queries
3.)prefer for big size application
Cons :-
1.) unnecessarily increase size of application
2.) little bit slow with compare to greenDao(another ORM)
To choose your ORM in android, also look at these links:
Bench marking ORMs in Comparison of SQLite
Comparison of GreenDao and ORMLITE
I'm creating an Android app with a Sqlite DB that has a couple of tables with pre-populated data (500+ rows) and also has tables which will be user populated.
The way I plan on distributing the database is via the following method for adding a pre-populated database to an app Using your own SQLite database in Android applications.
I have an issue with this however as when it comes to upgrades I will likely either be adding a number of rows to the pre-populated tables and possibly even modifying a lot of the data in the existing rows, I want to completely replace those existing tables with the tables from the new pre-populated tables, yet leave the user populated tables intact.
I found another post How do i upgrade my pre-populated sqlite database on my device without re-creating tables? where a user suggests this may be the wrong approach entirely ("The "right" way to do things is quite different from how you've set out") as I want upgrades to be as efficient as possible. As I haven't actually published my first version yet should I be changing my approach?
What is the most effective approach for this scenario?
The way I plan on distributing the database is via the following method for adding a pre-populated database to an app Using your own SQLite database in Android applications.
That code has been out of date for some time. Please consider using something more modern and supported, like SQLiteAssetHelper.
I want to completely replace those existing tables with the tables from the new pre-populated tables, yet leave the user populated tables intact
SQLiteAssetHelper supports two patterns out of the box:
Replace the entire database with the new packaged copy
Run your own SQL scripts to update the existing installed database, ignoring the copy packaged with your app
Since SQLiteAssetHelper is open source, you can see how Jeff Gilfelt wrote it and try to leverage that for somehow supporting your hybrid scenario.
Personally, unless you need to do joins between "pre-populated tables" and "user populated tables", I would encourage you to use two separate databases. One would be all of the pre-populated data, which you could replace completely as needed based on app updates. The other would hold the user tables, which you would handle with a more conventional SQLiteOpenHelper. And, you might be able to do joins even with two separate databases, using ATTACH DATABASE, though I have not personally tried that scenario.