Why use h2 when you can use SQLite? #19

Closed
billmccord opened this Issue Dec 10, 2010 · 2 comments

Projects

None yet

2 participants

@billmccord

I just finished building you code and running your tests and all of them passed. Then I made a few very simple changes:

  1. I pulled the jar SQLite JDBC jar from the following link and dropped it into your lib folder:
    http://www.zentus.com/sqlitejdbc/
  2. I changed the SQLiteDatabase to use this SQLite JDBC binding instead of h2:
    //Class.forName("org.h2.Driver").newInstance();
    Class.forName("org.sqlite.JDBC").newInstance();
    //connection = DriverManager.getConnection("jdbc:h2:mem:");
    connection = DriverManager.getConnection("jdbc:sqlite:mem:");
  3. I ran the tests again and all the SQLite related ones passed.

What advantage is there to using h2 when Android uses SQLite?

@pivotal
pivotal commented Dec 10, 2010

The reason h2 was chosen is because sqlite requires native binaries. Here's a recent discussion in the robolectric google group:

http://groups.google.com/group/robolectric/browse_thread/thread/827986ac3320d707/ac77b470ecd5ece3?lnk=gst&q=sqlite#ac77b470ecd5ece3

We'll add a story to our backlog for making the database connection strings configurable.

-Phil & Tyler

@billmccord

Ok, so it requires native binaries, but all of the major OSes are covered by the one I sent (Windows, Linux, and Mac OS X.) The problem is that h2 is not a good substitution for SQLite. I have already run into numerous cases where it does not reproduce the same results for code I am trying to test. It doesn't support many of the queries, triggers, or virtual tables (especially those using fts3) very robustly.

Making the database configurable would be great! For now, I will use my modified branch of your code. Thanks!

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment