You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 25, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 25, 2024. It is now read-only.
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.
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).
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.
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.getTypehttps://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?
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.
Activity
alexander-yakushev commentedon Mar 12, 2015
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 commentedon Mar 12, 2015
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 commentedon Mar 12, 2015
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
1and"1"respectively. It also doesn't have boolean type.sattvik commentedon Mar 16, 2015
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.getTypehttps://www.sqlite.org/datatype3.html. Perhaps what we should do is something like the:key-fnand:value-fnsupported 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 commentedon Mar 16, 2015
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 commentedon Mar 16, 2015
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.