Here is my model classes that are persisted in sqlite db using ORMLITE.
public class Site{
...
...
Collection<Visit> visits;
}
public class Visit{
...
...
Collection<Pic> pics;
}
public class Pic{
...
...
}
Now in one view i add,edit or delete from these three tables. There is a button in my view to cancel the changes(add,edit,delete). So i need to rollback to previous state of the db.
How can i achieve this roll back to a certain state of the three tables using ormlite with android?
I have read in ormlite docs about DAO.SetAutoCommit() and startThreadConnection() methods. I think i can do it by using this two. But cant figure it out how to use them. Please suggest me how to do it.
Here is my DBHelper Class:
public class DatabaseHelper extends OrmLiteSqliteOpenHelper {
// name of the database file
private static final String DATABASE_NAME = "Test.db";
private static final int DATABASE_VERSION = 1;
private Dao<Site, Integer> siteListDao = null;
private Dao<Visit, Integer> visitDao= null;
private Dao<Pic,Integer> picDao=null;
public DatabaseHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
#Override
public void onCreate(SQLiteDatabase database,ConnectionSource connectionSource) {
try {
TableUtils.createTable(connectionSource, Site.class);
TableUtils.createTable(connectionSource, Visit.class);
TableUtils.createTable(connectionSource, Pic.class);
} catch (SQLException e) {
Log.e(DatabaseHelper.class.getName(), "Can't create database", e);
throw new RuntimeException(e);
} catch (java.sql.SQLException e) {
e.printStackTrace();
}
}
public Dao<Visit, Integer> getVisitDao() {
if (null == visitDao) {
try {
visitDao = getDao(Visit.class);
}catch (java.sql.SQLException e) {
e.printStackTrace();
}
}
return visitDao;
}
.....
.....
Hmm don't know about any methods that will do this for you automatically. If you really wanna do it automatically, you could also check out Transactions. They have build-in controls to roll-back on fail. Not exactly what you want, but maybe adjustable.
You could also just do it more manually and save 1 (last) object in memory, the object you're going to delete. If a person wants to 'undo' the change, you can just re-add that object with ORMLite. Probably a lot easier than other options.
Yeah I mostly agree with #Stefan. I think you need to do this inside of your application and not rely on a database construct to all you to return to a previous state.
Turning off auto-commit (which ORMLite uses transactions under Sqlite) or using transactions directly is not how to do this. Transactions are designed to allow you to make multiple changes to the database and then roll them all back if one database change fails. They are not intended to stay open for seconds waiting for user input.
You could have a committed boolean field or some such in your data to make it easier to "revert" the database by deleting all objects where the committed = false or some such.
You could have separate tables so objects are stored to a session table and then copied over to the main tables when the user commits their work.
Related
I have an SQLite database that I created in Android that I'm manually managing all the code for to perform my reading and writing. I recently discovered ORMlite. I want to use ORMlite to manage my database from this point forward. The issue is the application is already on the android market and I don't want my user's to lose their data.
Is there a way I can tell ORMlite to start managing the already made database? Or is there a standard practice to read all of my data from the old database and write it to a new one?
Well after doing a fair amount of due diligence I realized how simple of a task this is. Ormlite actually sits on top of the built-in SQLite. No code is needed to move to Ormlite. I simple reference my database name within my Ormlite Helper Class.
My code is below. I hope this helps someone else in the future.
public class OrmHelper extends OrmLiteSqliteOpenHelper {
private final String TAG = this.getClass().getSimpleName();
private Context context;
public OrmHelper(Context context) {
//references my Sqlite dbnames. I made them static in the SqlHelper class
super(context, DataBase.DB_Name, null, DataBase.DB_Version);
this.context = context;
}
#Override
public void onCreate(SQLiteDatabase database, ConnectionSource connectionSource) {
try {
Log.i(TAG, "Creating database in Ormlite");
TableUtils.createTable(connectionSource, Model.class);
TableUtils.createTable(connectionSource, UserCredential.class);
} catch (SQLException e) {
Log.e(TAG, "Error creating database", e);
}
}
#Override
public void onUpgrade(SQLiteDatabase database, ConnectionSource connectionSource,
int oldVersion, int newVersion) {
}
/**
* this genric method is for grabbing the Dao for any ormlite table
*/
public <T, V> Dao<T, V> getTypeDao(Class<T> classType, Class<V> idType)
throws SQLException{
return getDao(classType);
}
}
There are a few Android APIs (after donut and before honeycomb) if Im not mistaken, where Google have enabled the AsyncTasks to run paralelly aiming for faster execution. Then lots of devs made mistakes when reaching out to the same database using multiple AsyncTasks, and since Android 3.0 AsyncTasks are running serially by default.
I am suffering this problem now when testing my app on an Android 2.3.4 device with my SQLite
First, Im getting categories from the server, I open DB, insert them close DB.
Second I get the subcategories from the server, open DB, insert them into DB, close DB
Third I get user items from the server, open DB, insert items, then close DB
Im taking good care to ensure that one starts after another, but in every 8-10 iterations something somewhere slows down and overlaps with another procedure right in the moment where a task is opening the db, another task closes it right after, and the first task starts trying to write to a closed db....
What do I do? I want clean, reliable separation, sequential execution and I dont want to start the asynctasks from the previous asynctask's onPostExecute, because these three will not always run in a row
I read an article yesterday that you CANT do it on android 2.x
Shall I try to open the DB and DBHelper before ALL of the operations and close the DB afterwards?
EDIT: Usually I get the error here (at Begin transaction):
(The error says that the DB is closed)
#Override
protected Void doInBackground(Void... arg0) {
// dbTools.close();
try {
if (database == null) {
database = dbTools.getWritableDatabase();
}
} catch (Exception e) {
e.printStackTrace();
}
ContentValues values = new ContentValues();
database.beginTransaction();
try {
// Iterating all UserItem objects from the LinkedHashSet and getting their info
for (UserItem userItem : userItems) {
// Inserting values for the database to insert in a new record
values.put(C.DBColumns.ITEM_ID, userItem.getItemId());
values.put(C.DBColumns.ITEM_NAME, userItem.getItemName());
// database.insertWithOnConflict(C.DBTables.ITEMS, null, values, SQLiteDatabase.CONFLICT_REPLACE);
database.insert(C.DBTables.ITEMS, null, values);
} // End of For loop
database.setTransactionSuccessful();
} finally {
database.endTransaction();
}
// Closing all cursors, databases and database helpers properly because not closing them can spring lots of trouble.
if (database != null && database.isOpen()) {
try {
database.close();
} catch (Exception e) {
e.printStackTrace();
}
}
return null;
} // End of doInBackground
And this is my DBTOOLS CLASS:
public class DBTools extends SQLiteOpenHelper {
// Its a good practice for DBTools to be a singleton. Do not instantiate it with "new DBTools(context)" but with
// DBTools.getInstance(context) instead
private static DBTools sInstance;
public static DBTools getInstance(Context context) {
if (sInstance == null) {
sInstance = new DBTools(context);
}
return sInstance;
}
public DBTools(Context context) {
super(context, C.Preferences.LOCAL_SQLITE_DATABASE_NAME, null, 1);
}
public void onCreate(SQLiteDatabase database) {
database.execSQL(SQLQueries.tableCategoriesCreate);
database.execSQL(SQLQueries.tableSubcategoriesCreate);
database.execSQL(SQLQueries.tableItemsCreate);
}
public void onOpen(SQLiteDatabase database) {
database.execSQL(SQLQueries.tableCategoriesCreate);
database.execSQL(SQLQueries.tableSubcategoriesCreate);
database.execSQL(SQLQueries.tableItemsCreate);
}
public void onUpgrade(SQLiteDatabase database, int version_old, int current_version) {
database.execSQL(SQLQueries.tableCategoriesDrop);
database.execSQL(SQLQueries.tableSubcategoriesDrop);
database.execSQL(SQLQueries.tableItemsDrop);
onCreate(database);
}
} // End of Class
Since you can't call from onPostExecute, I would say you have two options, one would be to move your open close calls to the beginning and end of your activity or service.
Option two would be to setup a reference counter in your DB and DBHelper where you track the number of times open has been called, and then decrement that count when close is called. That way you can perform close only when the count is 0. One thing to remember when taking this approach is that you should probably have a method that will force the db to close that you call when you are sure your other connections are done. This shouldn't be necessary but will be a failsafe to ensure the db gets closed if something goes wrong.
Edit: You would have to make DBTools a singleton for it to work, but it's not equivalent. Here's a quick example.
public class DBTools {
private static DBTools instance;
private static int openCount;
public DBTools getInstance() {
if (instance == null) {
instance = new DBTools();
}
return instance;
}
private DBTools() {
openCount = 0;
}
public void open() {
openCount++;
//Do open
}
public close() {
openCount--;
if (openCount == 0) {
//Do close
}
public void forceDBClose() {
//Do close
}
}
I am also a newbee in android. I was having a problem like this too.
To overcome this, i used Singleton class.
I created one instance of the DBHelper class and used it in all my asynctasks.
So, until the DB is closed, all the asynctasks access the initialised DB object.
If there is no object in the memory, the async tasks, instantiates it and use it then.
I don't know how to handle this correctly without getting database locked errors.
My app basically downloads many items in batches of 100 rows (~ 60.000 items) and inserts them in the database. Each batch of 100 rows is processed into a transaction.
The main activity allows the user to navigate between screens (fragments) while records are being downloaded and inserted. Most of the other screens contains read data from the database. I get a lot of database lock errors during reading. All readings are done in the main activity (not fragments) in different async tasks
So far I just used the "classic approach"
public class DBAdapter {
public DBAdapter(Context ctx) {
this.context = ctx;
DBHelper = new DatabaseHelper(context);
}
private static class DatabaseHelper extends SQLiteOpenHelper {
DatabaseHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
#Override
public void onCreate(SQLiteDatabase db) {
db.execSQL(DB_CREATE_TABLES);
}
#Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
Utils.log("Upgrading database from version " + oldVersion + " to " + newVersion + ", which will destroy all old data");
onCreate(db);
}
public DBAdapter open() throws SQLException {
database = DBHelper.getWritableDatabase();
return this;
}
public void close() {
DBHelper.close();
}
Then on my activity's onCreate() I call db = new DBAdapter(context); and each time I am doing an database operation (read/write) I call db.open() and after the insert/read is done I call db.close()
My questions are:
what would be the best approach to this situation ?
Considering I do a lot of write/read would it be better to call db.open on onCreate and db.close() on onDestroy() ? Would this be better than calling open/close each time I need to access the database ?
What do I need to do to avoid database locking on reading ?
I had a exactly similar situation like yours. In addition to what you described, in my app the user also can update the database through input on the screen.
The way I resolved it ( I don't know if it's the best way, but I hardly see any locking issue now)
Make a singleton class derived from SQLiteOpenHelper to make sure only one instance is running at any given time.
Implement ContentProvider class for insert/update/delete/query operations. Make all those functions 'synchronized'
Only close the db in ContentProvider's shutdown function. I do a very frequent db operations, so I don't want to open/close everytime. But I am not sure if it's the correct way of handling it.
Do access DB only through ContentProvider interface from anywhere
A very simple approach, or maybe a workaround is using synchronized methods for opening and closing the database object. I don't really know if it's the best practice, but at least it's simple and easy. Add this methods to your DBAdapter Class, and use them instead of db.open and db.close. The use_count attribute simple holds how many times open has been called. Initialize it with a value of 0. Also, in order to make it work on your solution be sure to pass the same DBAdapter object between the fragments. Don't create a new one everytime :
private int use_count = 0;
public synchronized void doOpen()
{
use_count++;
this.open();
}
public synchronized void doClose()
{
use_count--;
if (use_count == 0)
{
this.close();
}
}
Consider wrapping the SQLite database in a ContentProvider and using CursorLoader to do the queries from the various activities & fragments. This isolates the management of the database from the Activity/Fragment life cycle and can result in many fewer open/close cycles.
You may still run into contention between the reads and writes, but having all the database interaction in the same module should make it easier for you to address these issues.
Some interesting links: http://www.vogella.com/articles/AndroidSQLite/article.html#todo
When to use a Content Provider
I have created a database in my application with 5 tables. my database is being updated from different threads. When i see the log i can see that there are database locked exception while opening the database if it is already open.
One of my friend suggested me to always use content provider to avoid this issue. According to him content provider manages concurrency issues on its own?
Is it a good practice to use content provider if we don't want to share data to other applications?
I think using a read-write lock is enough in most cases.
Suppose you have written the following,
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
public class MyDatabase extends SQLiteOpenHelper
{
private static final ReadWriteLock rwLock = new ReentrantReadWriteLock(true);
private static void beginReadLock()
{
rwLock.readLock().lock();
}
private static void endReadLock()
{
rwLock.readLock().unlock();
}
private static void beginWriteLock()
{
rwLock.writeLock().lock();
}
private static void endWriteLock()
{
rwLock.writeLock().unlock();
}
then you can do your task like the following.
public static void doSomething()
{
SQLiteDatabase sldb = null;
try
{
beginReadLock();
MyDatabase mydb = new MyDatabase();
sldb = mldb.getReadableDatabase();
......
}
catch (Exception e)
{
......
}
finally
{
if (sldb != null)
{
try
{
sldb.close();
}
catch (Exception e) {}
}
endReadLock();
}
}
Enclose read operations with beginReadLock() and endReadLock(). Likewise, enclose write operations with beginWriteLock() and endWriteLock().
Months ago, by the solution described above, I could solve my own database-lock issue where multiple threads were trying to read/write-open a database simultaneously.
The problem is that you use several database connections to your database. Thus, several threads try to update your table simultaneously and all these threads have different connections to your database.
To avoid this problem in all your threads you need to use the same connection to the database, i.e. all your threads should use the same connection to the database (that is represented by SQLiteDabase object).
Moreover, so as there is a file block on a sqlite file you'll not improve the performance of database upgrade using several threads (it's better to use only one thread to work with database). If you want to use several threads, you should use the same connection to the database and in this case Android will manage locks.
The discussion of this problem you can find here: http://touchlabblog.tumblr.com/post/24474398246/android-sqlite-locking and here: What are the best practices for SQLite on Android?
Hi I am new to android and I have a problem in creating a database.
public class database extends ListActivity {
/** Called when the activity is first created. */
private final String MY_DATABASE_NAME = "myCoolUserDB.db";
private final String MY_DATABASE_TABLE = "t_Users";
Context c;
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ArrayList<String> results = new ArrayList<String>();
setContentView(R.layout.main);
SQLiteDatabase mydb=null;
try
{
mydb.openOrCreateDatabase(MY_DATABASE_NAME, null);
} catch(Exception e){}
}
}
When I run this code it throws a run time exception. Please help me.
If you are going to call a static method like openOrCreateDatabase, do it on the class (SQLiteDatabase.openOrCreateDatabase(...)), not an instance. It's a lot clearer - the way you've done it looks like you're calling an instance method, so looks like a sure NullPointerException, which of course is misleading.
As someone else has stated, the stack trace would be the most useful thing when asking for help with an exception.
(Almost) never catch an exception without at the very least logging it. Don't just do nothing with it. There are of course exceptions to every rule, but let's not go there for the moment. Anyway, if you don't at least log it, you're just throwing away information that would tell you what went wrong when everything goes to crap later.
You shouldn't be using that method directly, and should instead be extending SQLiteOpenHelper . See the android developers page on data storage to get started (I'd post a link but apparently I'm only allowed one link in my post ?!), and since you've probably had to download the SDK to get going, look in the samples that come with it for the Notepad sample application. That contains a NotePadProvider class, which is a good example of both a content provider and database access, which often go hand-in-hand on android. I'd suggest compiling that application and making some simple changes to it before you jump into making your own one.
For working with sqlite database you need to create class extended from SQLiteOpenHelper:
private class DBHelper extends SQLiteOpenHelper {
public DBHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
#Override
public void onCreate(SQLiteDatabase db) {
db.execSQL(CREATE_TABLES);
}
#Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
db.execSQL(UPGRADE_TABLES);
}
}
Then you can get access to db using DbHelper object:
DBHelper dbHelper = new DBHelper(Activity.this);
SQLiteDatabase db = dbHelper.getReadableDatabase();
I run into the same problem. It figures out that two bugs happens during development
dir "databases" was not existent
accendently ".db" was created as directory.
They following code cover both
File dbFile = getDatabasePath ("abc.db");
if (dbFile.isDirectory ()) {
dbFile.delete();
}
if (! dbFile.exists()) {
String path = dbFile.getParent ();
new File (path).mkdirs ();
}
database = SQLiteDatabase.openDatabase (dbFile.getAbsolutePath (), this, SQLiteDatabase.OPEN_READWRITE | SQLiteDatabase.CREATE_IF_NECESSARY);
Hope this helps
I think SQLiteOpenHelper is only useful for "single table" databases. For multiple table applications I consider directly using SQLiteDatabase fit better to a good architecture.
This is a simple post which tells you how to insert data in to a SQLite database in Android and further more this links shows you how to retrieve data from a SQLite database in Android .