Sorry for being dense, but I don't understand what you are saying.
What do you mean by "prepare a transaction"? Transactions are not
prepared, statements are. sqlite3_prepare is not part of a
transaction, does not initiate a transaction, and is not affected by
any ongoing transaction in any
- Original Message -
From: "Dennis Cote" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Friday, November 04, 2005 8:48 AM
Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
Robert Simpson wrote:
It's 100,000 more memory alloc
Dennis Cote <[EMAIL PROTECTED]> writes:
> Furthermore, I don't believe that most users are using an authorizer anyway
> (but I could definitely be wrong about that). In that case all the authorizer
> callbacks become no-ops don't they?
PHP's use of sqlite uses an authorizer callback in the
Rob Lohman wrote:
This all starts to feel a bit "unsafe". What would happen if a program
would load a library that houses the callback and it gets unloaded
after the first prepare? Or is it a rule you need to have the callback
available for the entire run of the virtual machine?
It would have
On 11/4/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The authorizer is used to protect against SQL injection attaches
> when the SQL text originates from user input. Typically an
> application will turn the authorizer on when preparing user-supplied
> SQL then turn it right back off again
On 3 Nov 2005, at 13:18, [EMAIL PROTECTED] wrote:
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt.
I'm in favour of this change. I think any code that wraps around
prepared/reusable queries will have
Robert Simpson wrote:
It's 100,000 more memory allocations and about 4.6mb of string copies
SQLite is doing behind the scenes. Every time SQLite prepares a
statement it allocates and copies the string. If you're inserting a
million rows into a database using the above "cheese" method (which
Rob Lohman wrote:
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt. Then when a
schema change occurred, the statement was automatically
recompiled and rebound. There would no more SQLITE_SCHEMA
errors.
Robert Simpson wrote:
- Original Message - From: "Dennis Cote" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Thursday, November 03, 2005 4:14 PM
Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
Robert Simpson wrote:
This is one
> That would compel me to change *all* of the API to use a
> "sqlite4_" prefix instead of "sqlite3_".
I'm guessing that eventually backwards compatibility will be broken
in such a way that there will be an sqlite4 (and perhaps an sqlite5
down the line). When that happens you might consider using
"Ulrich Telle" <[EMAIL PROTECTED]> wrote:
>
> Sure, it would be nice if SQLITE_SCHEMA errors could be handled internally
> by SQLite, but I think it's a non-trivial task to handle this kind of error.
>
> When I created my SQLite C++ wrapper wxSQLite3 I thought about handling
> SCHEMA errors, but
Suppose this where to
change in version 3.3.0 so that the actual error code
was returned by sqlite3_step().
Would it still be necessary to call sqlite3_finalize?
If so then I don't see the point of the API change.
Then when a schema change occurred, the statement was
automatically recompiled
API changes for SQLite are fine with me as long as the PHP folks keep up
with SQLite in terms of implementing SQLite hooks.
I'm not real experienced with SQLite, but I'm starting to learn a lot. I
use it with PHP 5.1 and PDOs. I find myself compiling the latest SQLite
CVS and the latest
> -Original Message-
> From: Darren Duncan [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 03, 2005 6:28 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
>
> At 4:22 PM -0700 11/3/05, Robert Simpson wrote:
At 4:22 PM -0700 11/3/05, Robert Simpson wrote:
It's 100,000 more memory allocations and about 4.6mb of string
copies SQLite is doing behind the scenes. Every time SQLite
prepares a statement it allocates and copies the string. If you're
inserting a million rows into a database using the
Robert Simpson wrote:
This is one gives me pause. I see lots of people doing things like
this in their code (Using C# since I address this in my wrapper's
helpfile and its convenient):
using (SQLiteCommand mycommand = new SQLiteCommand(myconnection))
{
int n;
for (n = 0; n < 10; n
- Original Message -
From: <[EMAIL PROTECTED]>
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR. Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code. Suppose this where to
change in
To summarize my thoughts on this thread so far:
1. None of the stuff being discussed should cause a major version
change, such as to 4.x.y; a big leap like that should only be taken
for large and sweeping changes, such as incompatible file formats or
paradigm shifts.
Mainly, they should be
Dennis Cote wrote:
I think both of these proposed changes are useful enhancements to SQLite.
I also think it would be better to add a new sqlite3_step_v2() API
function that does this. This will eliminate the need to change the base
version number, since existing code can continue to use the
On 3 Nov 2005, at 08:18, [EMAIL PROTECTED] wrote:
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR. Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code. Suppose this where to
change in version
:-) A very nice description of C. Unfortunately, it's the best
cross-platform/cross-language tool available for such a library.
Java and C++ have a whole other mess of compatibility problems - even
on the same platform. Try using a C++ shared library compiled in
GCC 2.9.x with code from GCC
Try using the ANALYZE command prior to querying under the latest version of
Sqlite. If that does
not work, please consider writing up a small test case and posting it to the
mailing list.
--- Preston Z <[EMAIL PROTECTED]> wrote:
> Any other hints about what is in the works for 3.3.0? I haven't
Rob Lohman wrote:
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt. Then when a
schema change occurred, the statement was automatically
recompiled and rebound. There would no more SQLITE_SCHEMA
errors.
On 11/3/05, Rob Lohman <[EMAIL PROTECTED]> wrote:
>
> Does anyone runs code that actually changes the schema of
> your database as the normal process in an application? If so,
> for what reason?
I believe the automatic vacuum can cause a schema change event.
[EMAIL PROTECTED] wrote:
What about this change? Is it a worth-while tradeoff?
Personally, I would like to see both of these changes.
On Thu, 3 Nov 2005, Rob Lohman wrote:
>>
>> I'm a big fan of this change. We do quite a lot of bookkeeping in our
>> own code to do exactly the same thing at the moment. It would make me
>> very happy to delete that code.
>
>This is not directly a question for you, Eric, but does anyone
>actually
2005 17:11
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
>> Another proposal: Suppose that when creating an sqlite3_stmt using
>> sqlite3_prepare, the original SQL text was stored in the
>> sqlite3_stmt. Then when a sche
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt. Then when a
schema change occurred, the statement was automatically
recompiled and rebound. There would no more SQLITE_SCHEMA
errors. But sqlite3_stmts
On Thu, 3 Nov 2005 [EMAIL PROTECTED] wrote:
>As currently implemented, when an error occurs during
>sqlite3_step(), the function returns SQLITE_ERROR. Then
>you have to call either sqlite3_reset() or sqlite3_finalize()
>to find the actual error code. Suppose this where to
>change in version
I would be in favor of both changes.
Any other hints about what is in the works for 3.3.0? I haven't upgraded
past 3.2.2 because the optimizer changes made my application hang and i
haven't had a chance to re-write & test all of my queries. Any changes in
3.3.0 that would allow me to upgrade
> Sent: Thursday, November 03, 2005 7:53 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Request for comment: Proposed SQLite API changes
>
>
> Cariotoglou Mike said:
>
> > a crappy .H file. these people (c programmers) live in wasteland, I
> > rea
[EMAIL PROTECTED] wrote:
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt. Then when a
schema change occurred, the statement was automatically
recompiled and rebound. There would no more SQLITE_SCHEMA
Cariotoglou Mike said:
> a crappy .H file. these people (c programmers) live in wasteland, I
> really admire them for the constructive way they use header files,
> include files, defines, make files, configure files and what not,and
> still manage to write code that is write-once, compile
vember 03, 2005 5:10 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Request for comment: Proposed SQLite API changes
>
> Thanks. I guess I never considered using two different
> releases of any product within the same executable. Wonder
> how many use this feature an
do it.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 03, 2005 4:05 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
>
> Dan Kennedy <[EMAIL PROTECTE
[EMAIL PROTECTED] wrote:
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR. Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code. Suppose this where to
change in version 3.3.0 so that the actual
The first proposal seems to me a very good one and contributes to
clarity in programs. The second one is of dubious value and a poor
tradeoff in my opinion.
JS
[EMAIL PROTECTED] wrote:
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR.
sqlite-users@sqlite.org
> Subject: RE: [sqlite] Request for comment: Proposed SQLite API changes
>
>
> It's a primitive form of namespaces in C.
> Renaming the function calls allows Sqlite2 and Sqlite3 to coexist
> within the same executable/binary.
>
> Mind you, if the functional
Ah, that explains why I get all those bugs in each new release of Oracle
:-)
> -Original Message-
> From: Jay Sprenkle [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 03, 2005 8:44 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Request for comment: Prop
> Just curious, why is this being done anyway? I think this is the only
> software product I have used that has this "feature." I fail to see the
> usefulness from way up here above the source code, and I don't have time
> to look deeper. But still curious as to why everybody has to rename all
-Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 03, 2005 7:56 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
>
>
> Joe Wilson <[EMAIL PROTECTED]> wrote:
On 11/3/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> >
> > With the recent numeric/integer/division change, the working
> > check clause and this proposed API changed shouldn't the version
> > number should be bumped to 4.0.0 to indicate
Dan Kennedy <[EMAIL PROTECTED]> wrote:
> > Another proposal: Suppose that when creating an
> > sqlite3_stmt using sqlite3_prepare, the original SQL
> > text was stored in the sqlite3_stmt. Then when a
> > schema change occurred, the statement was automatically
> > recompiled and rebound.
>
>
Joe Wilson <[EMAIL PROTECTED]> wrote:
>
> With the recent numeric/integer/division change, the working
> check clause and this proposed API changed shouldn't the version
> number should be bumped to 4.0.0 to indicate incompatibility with
> past versions?
>
That would compel me to change *all*
> Another proposal: Suppose that when creating an
> sqlite3_stmt using sqlite3_prepare, the original SQL
> text was stored in the sqlite3_stmt. Then when a
> schema change occurred, the statement was automatically
> recompiled and rebound.
This seems pretty handy, but it can be done in a
I'm for both changes...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 03 November 2005 13:18
To: sqlite-users@sqlite.org
Subject: [sqlite] Request for comment: Proposed SQLite API changes
As currently implemented, when an error occurs during sqlite3_step
I vote for the cleaner API changes even though they are
not 100% backwards compatible. Alternatively you could
have a brand new step function, leaving the old versions with
the same functionality.
With the recent numeric/integer/division change, the working
check clause and this proposed API
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR. Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code. Suppose this where to
change in version 3.3.0 so that the actual error code
was returned by
48 matches
Mail list logo