Sqlite insert lines bug


I am stuck on a really weird bug. I have a table followers, and when I insert datas, it works except for th me first entry.

The first time I call the function, nothing is thrown and the insert function return as expected 1. But when I call the select all function, the table is empty.

However when I call the function an other time with different parameters, the data are really inserted and the table shows one entry (this one) but with 2 as id.

I am using Sqldelight.

public long insertFollower(String name, String wca_id, long created_at) {

    try {
        SQLiteDatabase db = openDatabase();

        return db.insert(Follower.TABLE_NAME, null, Follower.FACTORY.marshal()

    catch (Exception e) {

    finally {

    return 0;

private static AtomicInteger openCount = new AtomicInteger();
private static SQLiteDatabase database;

public static final String DATABASE_NAME = "database.db";
public static final int DATABASE_VERSION = 12;

private static DatabaseHelper instance;

public static synchronized DatabaseHelper getInstance(Context context) {
    if(instance == null) {
        instance = new DatabaseHelper(context);

    return instance;

public synchronized SQLiteDatabase openDatabase() {
    if(openCount.incrementAndGet() == 1) {
        database = getWritableDatabase();

    return database;

public synchronized void closeDatabase() {
    if(openCount.decrementAndGet() == 0) {

public void onCreate(SQLiteDatabase db) {



And the Follower.CREATE_TABLE who was generated by sqldelight

  String CREATE_TABLE = ""
  + "CREATE TABLE follower (\r\n"
  + "    name TEXT NOT NULL,\r\n"
  + "    wca_id TEXT NOT NULL\r\n"
  + ")";


I noticed something strange that may help:

This works only if the table is empty

I insert a follower, that doesn't works. But when I insert an other follower with the same ID as the first one (there is a primary key autoincrement). I get a UNIQUE exception but the table is still empty.

Do not hesitate to ask more information.

Thank you.


I finally find the answer thanks to @anstrong: to select the follower I used cursor.moveToFirst() and the while(cursor.moveToNext()) was called just after

Was there a reason why you didn't choose to use an IOC Library (StructureMap, Ninject, Autofac, etc)? Using any of these would have made your life much easier.

Although David L has already made an excellent set of commentaries on your points, I'll add my own as well.

Much bigger codesize

I am not sure how you ended up with a larger codebase; the typical setup for an IOC library is pretty small, and since you are defining your invariants (dependencies) in the class constructors, you are also removing some code (i.e. the "new xyz()" stuff) that you don't need any more.

Ravioli-code instead of spaghetti-code

I happen to quite like ravioli :)

Slower performance, need to initialize all dependencies in constructor even if the method I want to call has only one dependency

If you are doing this then you are not really using Dependency Injection at all. You should be receiving ready-made, fully loaded object graphs via the dependency arguments declared in the constructor parameters of the class itself - not creating them in the constructor! Most modern IOC libraries are ridiculously fast, and will never, ever be a performance problem. Here's a good video that proves the point.

Harder to understand when no IDE is used

That's true, but it also means you can take the opportunity to think in terms of abstractions. So for example, you can look at a piece of code

public class Something
    readonly IFrobber _frobber;
    public Something(IFrobber frobber)

    public void LetsFrobSomething(Thing theThing)

When you are looking at this code and trying to figure out if it works, or if it is the root cause of a problem, you can ignore the actual IFrobber implementation; it just represents the abstract capability to Frob something, and you don't need to mentally carry along how any particular Frobber might do its work. you can focus on making sure that this class does what it's supposed to - namely, delegating some work to a Frobber of some kind.

Note also that you don't even need to use interfaces here; you can go ahead and inject concrete implementations as well. However that tends to violate the Dependency Inversion principle (which is only tangenitally related to the DI we are talking about here) because it forces the class to depend on a concretion as opposed to an abstraction.

Some errors are pushed to run-time

No more or less than they would be with manually constructing graphs in the constructor;

Adding additional dependency (DI framework itself)

That is also true, but most IOC libraries are pretty small and unobtrusive, and at some point you have to decide if the tradeoff of having a slightly larger production artifact is worth it (it really is)

New staff have to learn DI first in order to work with it

That isn't really any different than would be the case with any new technology :) Learning to use an IOC library tends to open the mind to other possibilities like TDD, the SOLID principles and so forth, which is never a bad thing!

A lot of boilerplate code, which is bad for creative people (for example copy instances from constructor to properties...)

I don't understand this one, how you might end up with much boilerplate code; I wouldn't count storing the given dependencies in private readonly members as boilerplate worth talking about - bearing in mind that if you have more than 3 or 4 dependencies per class you are likely to be in violation of the SRP and should rethink your design.

Finally if you are not convinced by any of the arguments put forth here, I would still recommend you read Mark Seeman's "Dependency Injection in .Net". (or indeed anything else he has to say on DI which you can find on his blog). I promise you will learn some useful things and I can tell you, it changed the way I write software for the better.

The majority of your concerns seem to boil down to either misuse or misunderstanding.

  • much bigger codesize

    This is usually a result of properly respecting both the Single Responsibility Principle and the Interface Segregation Principle. Is it drastically bigger? I suspect not as large as you claim. However, what it is doing is most likely boiling down classes to specific functionality, rather than having "catch-all" classes that do anything and everything. In most cases this is a sign of healthy separation of concerns, not an issue.

  • ravioli-code instead of spaghetti-code

    Once again, this is most likely causing you to think in stacks instead of hard-to-see dependencies. I think this is a great benefit since it leads to proper abstraction and encapsulation.

  • slower performance Just use a fast container. My favorites are SimpleInjector and LightInject.

  • need to initialize all dependencies in constructor even if the method I want to call has only one dependency

    Once again, this is a sign that you are violating the Single Responsibility Principle. This is a good thing because it is forcing you to logically think through your architecture rather than adding willy-nilly.

  • harder to understand when no IDE is used some errors are pushed to run-time

    If you are STILL not using an IDE, shame on you. There's no good argument for it with modern machines. In addition, some containers (SimpleInjector) will validate on first run if you so choose. You can easily detect this with a simple unit test.

  • adding additional dependency (DI framework itself)

    You have to pick and choose your battles. If the cost of learning a new framework is less than the cost of maintaining spaghetti code (and I suspect it will be), then the cost is justified.

  • new staff have to learn DI first in order to work with it

    If we shy away from new patterns, we never grow. I think of this as an opportunity to enrich and grow your team, not a way to hurt them. In addition, the tradeoff is learning the spaghetti code which might be far more difficult than picking up an industry-wide pattern.

  • a lot of boilerplate code which is bad for creative people (for example copy instances from constructor to properties...)

    This is plain wrong. Mandatory dependencies should always be passed in via the constructor. Only optional dependencies should be set via properties, and that should only be done in very specific circumstances since oftentimes it is violating the Single Responsibility Principle.

  • We do not test the entire codebase, but only certain methods and use real database. So, should Dependency Injection be avoided when no mocking is required for testing?

    I think this might be the biggest misconception of all. Dependency Injection isn't JUST for making testing easier. It is so you can glance at the signature of a class constructor and IMMEDIATELY know what is required to make that class tick. This is impossible with static classes since classes can call both up and down the stack whenever they like without rhyme or reason. Your goal should be to add consistency, clarity, and distinction to your code. This is the single biggest reason to use DI and it is why I highly recommend you revisit it.

By : David L

This video can help you solving your question :)
By: admin