The problem is you are defining your problem differently than SQLite does, so
it can’t help you.
To SQLite, a query with ?10 in it has (at least) 10 positional parameters, and
if you are defining that the user needs to explicitly provide values for all
parameters, (by SQLite) that means they will need to provide positional
parameters 1 - 10 (even if some are not used).
You seem to want to redefine that in this case, if a parameter isn’t actually
used, then it doesn’t need to be provided. To do this, my guess is you are
going to need to parse the SQL yourself (at least partially) to detect what
parameters are used.
Note, perhaps part of the issue is that you seem to want to call ?10 as a key
based placeholder, but to SQLite it is an index based placeholder, and implies
that indexes 1 through 9 also exist.
> On Jul 22, 2019, at 8:36 AM, test user <example.com.use...@gmail.com> wrote:
>
> I understand the problem, but I want my library to be able to detect the
> problem programatically.
>
> Currently if a user mixes index-based and key-based placeholders, the only
> thing a library using SQLite can do us run the query with unbound
> placeholders set to null (the SQLite default).
>
> Id like the ability to instead throw an error in this case.
>
>
> I think SQLite internally knows how many placeholders are in the query at
> parse time.
>
> My question is how can I get the data via the API, or if it would be
> considered to add a function to get this data?
>
>
>> On Mon, Jul 22, 2019 at 12:29 PM Keith Medcalf <kmedc...@dessus.com> wrote:
>>
>>
>>> On Monday, 22 July, 2019 04:34, Enzo <contact.enz...@gmail.com> wrote:
>>>
>>> It is not the same information.
>>
>>> I want to be able to determine "has the user bound all placeholder
>>> values with data?".
>>
>>> The user provides this as input:
>>
>>> query="SELECT ?, ?10"
>>> data={"0": "data-a", "10": "data-b"}
>>
>>> Note: This IS valid, as they have provided all data for placeholders.
>>
>>> Using the APIs you mentioned:
>>
>>> count=10
>>> name(10) = "?10"
>>
>>> So according to the API, the indexes [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> are placeholders in the query.
>>
>>> As you can see, only indexes [1, 10] are valid placeholders in the
>>> query.
>>
>>> So, as far as I can tell, it is not possible to get this from the
>>> API:
>>
>>> query="SELECT ?, ?10"
>>> valid_placeholder_indexes=[1, 10]
>>
>>> It is only possible to get this:
>>
>>> query="SELECT ?, ?10"
>>> maybe_placeholder_indexes=[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>
>> The fundamental issue is that you are confusing POSITIONAL parameters with
>> NAMED parameters. ?nnn where nnn is numeric describe POSITIONAL
>> parameters, so in the query SELECT ?, ?10 you are using positional
>> parameter 1 and positional parameter 10. That implies that there are 10
>> positional parameters. The fact that you are only using those positional
>> parameters sparsely (only using positional parameter 1 and positional
>> parameter 10) does not mean that you are using two parameters, it means
>> that you are using 10, but only referencing 2 of them.
>>
>> Said another way, you are declaring a function that looks like this:
>>
>> int stmt(a, b, c, d, e, f, g, h, i, j)
>> return a + j
>>
>> and expecting to be able to call it as
>>
>> z = stmt(1, 6)
>>
>> expecting some magic to know that the second parameter is really parameter
>> 10.
>>
>> https://www.sqlite.org/lang_expr.html#varparam
>>
>> There may be many positional parameters (like 999 in the default build)
>> and sqlite3_bind_parameter_count returns the "index" of the greatest
>> parameter number used in the statement. Having created 10 parameters
>> sqlite has absolutely no clue that you happen to be using only parameter 1
>> and parameter 10. If you only needed 2 parameters you should have only
>> created 2, not 10. That is what NAMED parameters are for.
>>
>> If you change from using positional (?) parameters to using named (:) or
>> (@) what happens?
>>
>> select :1, :10; should only create 2 parameters named :1 and :10 ...
>>
>> --
>> The fact that there's a Highway to Hell but only a Stairway to Heaven says
>> a lot about anticipated traffic volume.
>>
>>
>>
>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
