Make neko.data.sqlite cursor more generic

[sattvik]

I am currently looking into adding better content provider support into Neko. It would be nice if the Cursor support could be more generic so that it can support all Cursor objects, regardless of source.

[alexander-yakushev]

Do you say it should be able to take a Cursor and a separate column mapping? It used to be like that before, and it was pretty awkward, because sometimes you control how it is called, somehow you don't (e.g. in adapter's getData() method).

[sattvik]

Well, can't it get a column mapping from the cursor itself? I haven't fully studied all of the sqlite functionality to see how it all works.

[alexander-yakushev]

From what I know, it can't. Cursor has raw data that the developer should know how to extract. That said, you can call both getInt and getString on an integer column and get 1 and "1" respectively. It also doesn't have boolean type.

[sattvik]

Well, here's where things get a little tricky. Natively, SQLite does not support anything other than NULL, INTEGER, REAL, TEXT, and BLOB columns, which is reflected in the Cursor.getType https://www.sqlite.org/datatype3.html. Perhaps what we should do is something like the :key-fn and :value-fn supported by clojure/data.json https://github.com/clojure/data.json#converting-keyvalue-types. I think that in the case of Neko's SQLite code, using information from the schema makes sense. However, that should be built on top of more generic functionality that can be of use when not using cursors from SQLite. What do you think?

[alexander-yakushev]

OK, I now see what you mean. Uniformly handling cursors from both SQLite and ContentProviders is desirable. However, it is important here (as with everything in Clojure-Android) to not make the overhead so significant that developers would forgo the wrapper and just use interop methods.

Right now I moved n.d.sqlite more towards constructing raw SQL queries (because I wanted the support for querying multiple tables). But ContentProvider business relies exclusively on their own query API. So I guess the best course of action would be to extract common code, and then provide two separate Neko namespaces for working with sqlite and with content providers.

[sattvik]

I agree. The only common code is related to cursors and getting data from cursors. Otherwise, we need separate APIs for SQLite vs. content providers.