sqlite.input refactoring

[springmeyer]

I'm moving large chunks of logic out of bind() and looking at removing auto-indexing to just be an api call that a developer would need to use (not triggered on load). This is all helpful to to ensure correctness of the key_field handling because the size of the code makes following the logic hard. Will work on this tomorrow.

[kunitoki]

i'm for this:

• favour user defined parameters and avoid doing any metadata calls if don't needed
• for every user unspecified parameter, collect and prepare the fastest way to query all of the remaining data in a single batch

and, be careful when using rowid (i would avoid it like tha plague), that will lead to wrong results every time you manipulate your table (aka insert/delete). we should rely on PK only, as that ensure the rtree is always consistent.

[springmeyer]

@kunitoki - Yes, I'm actively working on avoiding rowid hardcoding (now that we can autodetect primary key via table_info) - making good progress, thanks for the suggestion.

I'm also in favor of fastest possible initialization if no user-defined parameters are passed, but when they are passed then skipping lookups wherever possible.

I'm also actively thinking about making some requirements, like extent, able to be more lazily evaluated.

[springmeyer]

sqlite-refactor branch now merged, closing. indexing functionality has been abstracted out, but auto-indexing is still in place. plan to move this to an api call - that work is underway into indexing-api branch.