Support object mapping of query result rows

[JakeWharton]

Nobody wants to work with a Query and Cursor. Add support for mapping rows to objects. This should support both table-based and custom view-based objects.

[ahmedre]

how about something like this -

@Mapper
public interface Mapper {
    @Column.Mapper(0) long getId(Cursor c);
    @Column.Mapper(1) String getText(Cursor c);
    @Column.Mapper(2) Date getWhen(Cursor c);
}

one good thing about this is it works even for joins (since it's just a numeric position) - the unfortunate piece is that working with column numbers is problematic.

unfortunately, the alternative of this is also not great and is problematic due to the bug about not being able to use table.column in getColumnIndexOrThrow:

@Mapper
public interface Mapper {
    @Column.Mapper("notes._id") long getId(Cursor c);
    @Column.Mapper("notes.text") String getText(Cursor c);
    @Column.Mapper("todos.whence") Date getWhen(Cursor c);
}

thoughts?

[yesitskev]

In my opinion, It would be best if we could come up with a solution where the model can define the table structure, builders and mappings (preferably most of the boiler plating done by an annotation processor). As a user(developer), I don't want to have to define a ton of interfaces, builders, abstract classes just to get some models out of the database. This is one of my concerns I have as I watch this library mature through its infancy.

[AlecKazakova]

I agree with Kevin that we want to reduce boilerplate as much as possible, #16 is actually a great start on that. One thing we have to keep in mind is that we need something that works for every type of SELECT, things like SELECT count(*), SELCT table1.column, table2.column FROM table1 JOIN table2, SELECT *, SELECT table1.column AS alias, which are all pretty common occurrences.

[dany-kun]

Would it be possible to add an optional parameter like the following to the create method and call it later in the Query.run method?

/** Convert the query Cursor to the user model */
  public interface CursorModel<T>{
    T convertToModel(Cursor c);
  }

This would not reduce the boilerplate but just move the cursor mapping out of the observable flow/subscribe methods implementation.

[meoyawn]

@ahmedre that's just perfect, now we need to generate those Mappers from SQL strings, and look for type hints: initial creation script + all the migrations or assist the IDE plugin by hand

the second option is at least achieveable

[meoyawn]

@ahmedre and what's the bug with getColumnIndexOrThrow?

[ahmedre]

@adelnizamutdinov getColumnIndexOrThrow doesn't work with table.column, only with column - see http://androidxref.com/5.1.0_r1/xref/frameworks/base/core/java/android/database/AbstractCursor.java line 275 for details.

[patrickhammond]

A few months ago I put together https://github.com/madebyatomicrobot/vinyl to start to address some accumulated internal project pains with Cursors and mapping rows into objects. Not sure if something like that is what you would like to see in SQLBrite.

[PerfectCarl]

There is also sqlbrite dao

[JakeWharton]

Our solution to this is https://github.com/square/sqldelight and efforts around object mapping will be focused there.