search

clojure-android / neko

The Clojure/Android Toolkit
Other
297 stars 36 forks source link

Make neko.data.sqlite cursor more generic #41

Open sattvik opened 9 years ago

sattvik commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.