Frequently asked, development questions about greenDAO.
If your question does not relate to development, check the general FAQ.
Which Android version does greenDAO require?
greenDAO runs on Android versions 1.6 and higher.
What’s a good place to store SQLiteDatabase/DaoMaster/DaoSession?
As a rule of thumb it’s a good idea to store database related objects in Application scope. This way use can use the database/DAO objects across Activities. Leaving the database open for the life time of the application’s process makes things simple and efficient.
Can I use existing entity classes? Can I skip entity generation?
Using greenDAO 3 would be most simple with @Enity annotations. For greenDAO 2: In your generator project, call setSkipGeneration(true) on entities you do not want to generate. Like this, you have the most possible control over your entities at the cost of manual maintenance. However, this is considered advanced usage and should be reserved for special cases only: the recommended way is to generate entities and use “keep sections” to inject custom code into them. If you choose to skip entity generation, you must either provide a constructor with all property fields in the order they were added in the generator project. Or alternatively, call setConstructors(false) on entities to make greenDAO use setters instead of the constructor to create entities.
Are there primary key restrictions? (key types, composite keys, etc.)
See Modelling entities > Primary key restrictions.
How can I read or update just a single column?
This is not what greenDAO is about. In greenDAO, you always read and update entities consisting of sever properties. This is not an issue in most cases: greenDAO is very fast and reading/updating all properties is typically done at rates >10.000 entities per second (we regularly post performance values, e.g. in 2016). If you still want to have per-column access, you can always resort to SQL.
What ProGuard or R8 rules should I use?
See the README file on GitHub.
After I insert/delete entries to/from a to-many relation, there are some issues.
Keep in mind, that relations entries are cached in the entity. Depending on your issue, you may have to make manually updates or reset your to-many relation. Please read the documentation on relations closely for details. Especially the section “Modelling To-One Relations” should be relevant to you.
Inserting/updating/deleting entities runs very slow. What’s wrong?
Probably, you are inserting/updating/deleting entities without using a transaction. Thus each operation is considered a transaction and SQLite needs to write to disk and do a file sync for each operation. Running all operations in a single transaction is essential for performance (and usually makes sense in terms of consistency). It will run a magnitude faster. For example, running 1,000 inserts in a single transaction ran 500 times faster (!) than 1000 individual transactions in one of our performance tests.
In greenDAO, use DaoSession.runInTx(Runnable) to make the given Runnable run as a transaction. If you have a list of entities of the same type, you can use the insertInTx or updateInTx methods of the DAO class belonging to the entity.
Why do my queries slow down when the database table grows?
The first think to check if you have an index matching the WHERE clause of your query.
Testing / Unit Testing
How to setup some tests involving greenDAO entities?
greenDAO already comes with a couple of base classes for unit testing and generates stubs for JUnit test classes. For the base classes, have a look at the org.greenrobot.dao.test package inside the DaoCore project (also part of the default greenDAO jar). These test classes initialize an in-memory database and the greenDAO infrastructure (a DAO or DaoSession object). Also, it might be interesting to look at the DaoTest project, which is testing greenDAO itself. It makes extensive use of the base classes.
I am getting SQLiteFullException, what happened?
The database ran out of storage: SQLite needs more free disk space, but it ran out on the device. First check how big your database file is, and if this size is reasonable. If the size exceeds your expectations, you should open the database file with a database browser. Which tables carry a lot of data? Maybe you just forgot to prune old data.
A less likely scenario are fragmented databases. Calling SQLite’s command VACUUM from time to time may prevent fragmenting. However it won’t resolve low storage situation because VACUUM makes a copy of the database resulting in twice the amount of storage needed.