Drop the Marshal in favour of bindings

Current idea of what binding support will look like:

CREATE TABLE customer (
  _id INTEGER PRIMARY KEY AUTOINCREMENT,
  first_name TEXT NOT NULL,
  last_name TEXT,
  is_cool INTEGER DEFAULT 1
);

customer_for_id:
SELECT *
FROM customer
WHERE _id = ?;

insert_customer:
INSERT INTO customer (first_name, last_name)
VALUES (?, ?);

generates:

interface Customer {

  // SQL strings and interface methods

  class CustomerFactory {
    CustomerFactory(Customer.Creator creator, <Adapters needed for Customer>);

    public RowMapper<Customer> customerForIdMapper();

    public String[] bindCustomerForid(int _id);

    public void bindInsertCustomer(SQLiteStatement statement, String first_name, String last_name);
  }
}

If a named sql statement in a .sq file is a SELECT, then a custom mapper is generated. If a named sql statement in a .sq file is an insert/update/delete and contains bind arguments, then a bind compiled statement method is generated. If a named sql statement in a .sq file is a SELECT statement and has bind args then a bind string array method is generated (see #73).

I like using compiled statements over the SQLiteDatabase.insert/delete/update apis because it keeps the arguments and the query itself in one object and is a lot more efficient. But the real benefit is it eliminates the runtime-ish nature of ContentValues. There’s no room for mistakes in terms of satisfying all of the table requirements. If in my example i changed is_cool to not have a default value then the statement wouldn’t compile anymore. Similarly if I added a new column to customer than insert_customer wouldn’t compile.

To maintain compatibility with the current stuff there could be an extra method generated to replicate the behavior of the copy constructor:

public void bindInsertCustomer(SQLiteStatement statement, Customer customer);

which would pull out the first_name and last_name fields and bind them.

Also the whole factory thing is just to save plugging in adaptors/creators all over the place.

[AlecStrong]

You could also use this for CREATE TABLE statements since there are cases where binding is necessary. Eg:

CREATE TABLE test (
  _id INTEGER PRIMARY KEY AUTOINCREMENT,
  date TEXT AS Date DEFAULT ?
);

generates

public void bindCreateTable(SQLiteStatement statement, Date date);

so you can provide default values for columns that require an adapter.

[AlecStrong]

Bind args will be in next release. I’m leaving the Marshal there too for now to make migrating easier but the plan is still to deprecate it soon.