Develop Reference

What is the best place for SQLite default entires?

I am creating (in android studio) an app which has a couple basic tables. One will be a bunch of exercises (pull ups, push ups ect) and I would like to put a ton of common ones into the table by default.
Where in my code would be the logical place to do that? I have made a databaseHelper class which extends SQLiteOpenHelper. Just not sure if I should..
insert them all in onCreate()
make a databaseHelper method which inserts them all and call it elsewhere
other?

Create a database with your desired data, package it as an asset, and use SQLiteAssetHelper to automatically unpack it into the proper spot for you when you first try to work with the database. This will be faster than running your own transaction(s) to insert the data.

sql onUpgrade for new users

This is a trivial question, but I am afraid to put in production wrong code and that testing in devices/emulator could lead to cache problems that do not mirror the reality.
My assumptions:
As well documented on SO, I need to add a column to my DB, I decided to use ALTER table ADD column
in onUpgrade(), and to change the version in the constructor of the DB from 1 to 2, so that the constructor will recognize that is running the new version and the onUpgrade() function should be triggered.
My 2 problems:
1) MOST IMPORTANT. Let's assume old users will upgrade successfully the db, but what happens with new users that still have to create even the first row of the DB, will they be directed to OnCreate() and not onUpgrade() because version is 2, or to on OnCreate() and then onUpgrade(), or almost impossible directly in OnUpgrade() skipping for some API reason even onCreate()?
In other terms do I need to update the new column changing the old onCreate() comprehending the new added column?
2) in onUpgrade() after
ALTER <table> ADD <column>
logically do I have to CREATE a new table right? Should I call onCreate() that as an updated Table( ex. instead of the original 4 column, now has 5 columns)?

When getWritableDatabase() is called, it checks the database file. If it does not exist, onCreate is called. If it does exist, but has a wrong version, onUpgrade is called.
So onCreate is responsible for creating the database schema of the current version, while onUpgrade is responsible for changing some existing database to have the schema of the current version.
You could share code between onCreate and onUpgrade, but calling that code is your own responsibility; the framework will not check the version again after the onXxx callback has returned.

greenDAO and data validation

I'm looking into using greenDAO for my Android app, but I noticed it doesn't seem to support any kind of data validation other than "not null", "unique", and foreign keys, either on the SQL level (constraints defined when creating tables) or the Java level (validation logic in setter methods). "Keep sections" don't seem like they would be helpful in this case because you can't have them within individual methods. Am I missing something, or would I really need to add yet another layer on top of the generated Java objects if I wanted to validate input data? (I'm somewhat confused how the framework could be useful without providing any place to include validation logic.)

1.
You can write a method
boolean check ();
in KEEP-SECTION of the entity which you call manually before INSERT or UPDATE.
2.
Another possibility is to extend the sourcecode of greendao generator to support checks: In property.java you could add a method to Property.Builder
public Property.Builder check (String expr) {
property.checkConditon = expr;
}
Of course you would have to introduce the String checkCondition = ""; and use it for generating the dao in the dao-template.
Problem:
With new versions of greendao your changes would be lost (but then again new version may already contain such a feature)
3.
A third possibility is to copy the generated CREATE TABLE statement, modify it to fit your needs and call your modified statement instead of the original one or to drop the original table and call your statement.
Problem:
If your table changes you will have to repeat this.

Android concerns with restore database

Imagine the following scenario (I allow backup / restore from my app, I'm doing backup / restore white the entire file.db):
The user make backup of the database.
In the future I do an update on my application which has a new version of the database.
what would happen if the user restore the database with the old version?
How can I avoid this kind of problem?
It would be a good idea to use BackupHelper? I did a simulation of the worst scenario of my database and gave 20k, BackupHelper is recommended for less than 1mb, it would be a good idea to use it? I think my app will never exceed 100kb.

You access SQLite databases via a SQLiteOpenHelper, which provides three callbacks: onCreate(), onUpgrade() and onOpen().
The constructor declares a version parameter, and internally it compares the database version (which is stored in the file) with the supplied argument. If the requested version is newer than the file's, your onUpgrade(db, old, new) is called and you get a chance to alter tables, fill rows and so on.
The restore procedure should simply close all open cursors and helpers and copy the new file in.

May be this is not the best approach but you can do it as:
1- Store the DB Version in the database.
2- After restoring the database, check the DB Version and do the required changes accordingly. Like
void afterRestoration()
{
long dbVersion = get from db;
if(dbVersion == 1)
{
alter table1 add column1;
}
else
{
}
}

xhange classes attributes in existing db4o in android

I'm considering to use db4o in my android project to store objects but my concern is if in the future I want to change one of the objects attributes how do i deal with the existing data of that object in the db4o file? I know in sqlite3 environment this can be done by altering the table structure in the onUpgrade() method, so how does db4o deal with this?

in db4o it really depends on what the changes are.
Adding field: You just add it. The new field will have the default value of that type. (null for references, 0 for numbers)
Removing a field: db4o will just ignore the removed field. You can access the old data of the removed field. As soon as you update the object the value of the old field will be removed.
Renaming fields and classes can be done with this call.
Changing the type of a field. That's like adding a new field. You need to copy the values over yourself. See here.
Adding interfaces has no effect on db4o.
Removing a type from the inheritance hirarchy: Not supported.
In general, take a look here.