-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/06/13 10:31, Maxim Khitrov wrote:
> I'm writing SQLite bindings for Go [1].
I'm the author of SQLite bindings for Python - APSW. One choice I made
was to mimic SQLite semantics into Python - essentially if it is a
function call/expensive operat
On Thu, 13 Jun 2013 21:27:33 -0400
Igor Tandetnik wrote:
> On 6/13/2013 9:15 PM, Maxim Khitrov wrote:
> > This works and also triggers SQLITE_SCHEMA with v1 interface. I did
> > a few more tests and it looks like the schema changes are ignored
> > if the statement is in the middle of iteration. A
IMO you should provide a function to invalidate the cache and also one
to check the schema version number, then leave it to the application
to decide when or if to bother with this.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8
On Fri, Jun 14, 2013 at 12:56 PM, Maxim Khitrov wrote:
> On Thu, Jun 13, 2013 at 9:27 PM, Igor Tandetnik wrote:
>> On 6/13/2013 9:15 PM, Maxim Khitrov wrote:
>>>
>>> This works and also triggers SQLITE_SCHEMA with v1 interface. I did a
>>> few more tests and it looks like the schema changes are i
On Fri, Jun 14, 2013 at 1:16 PM, Simon Slavin wrote:
>
>
> On 14 Jun 2013, at 5:56pm, Maxim Khitrov wrote:
>
>> Unconditionally invalidating the cache after each initial call to step
>> will add a bit of overhead when repopulating the values.
>
> Do you think that every single user of SQLite does
On 14 Jun 2013, at 5:56pm, Maxim Khitrov wrote:
> Unconditionally invalidating the cache after each initial call to step
> will add a bit of overhead when repopulating the values.
Do you think that every single user of SQLite does this ? Have you ever seen
it included in the source code of a
On Thu, Jun 13, 2013 at 9:27 PM, Igor Tandetnik wrote:
> On 6/13/2013 9:15 PM, Maxim Khitrov wrote:
>>
>> This works and also triggers SQLITE_SCHEMA with v1 interface. I did a
>> few more tests and it looks like the schema changes are ignored if the
>> statement is in the middle of iteration. As y
On 6/13/2013 9:15 PM, Maxim Khitrov wrote:
This works and also triggers SQLITE_SCHEMA with v1 interface. I did a
few more tests and it looks like the schema changes are ignored if the
statement is in the middle of iteration. As you said, only the first
step after a prepare/reset causes the values
On Thu, Jun 13, 2013 at 8:36 PM, Igor Tandetnik wrote:
> On 6/13/2013 8:29 PM, Igor Tandetnik wrote:
>>
>> The column addition should have failed, unless you are using WAL in
>> which case changes made by the writer are not visible to outstanding
>> readers. A useful test would be to prepare the s
On 6/13/2013 8:29 PM, Igor Tandetnik wrote:
The column addition should have failed, unless you are using WAL in
which case changes made by the writer are not visible to outstanding
readers. A useful test would be to prepare the statement, then get
column count (without ever stepping), then add th
On 6/13/2013 8:04 PM, Maxim Khitrov wrote:
I'd like to check my assumptions. After preparing a statement using
the v2 interface, which functions are guaranteed to return the same
values for that statement instance? These are the ones that I'm
interested in at the moment:
sqlite3_bind_parameter_c
Hello,
I'd like to check my assumptions. After preparing a statement using
the v2 interface, which functions are guaranteed to return the same
values for that statement instance? These are the ones that I'm
interested in at the moment:
sqlite3_bind_parameter_count
sqlite3_bind_parameter_name (for
12 matches
Mail list logo
