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
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 decided
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 macro
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 gives me pause. I see lots
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:
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 I
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
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 so that
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
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 original
- 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 allocations and about 4.6mb of string
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
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
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
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 wrapper.
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* of the
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.
The
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 incompatibility with
past
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:
With the recent numeric/integer/division change
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
their
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: Proposed SQLite API changes
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 functionality of a documented function changes
(as opposed
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.
[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
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 PROTECTED] wrote:
Another proposal
, 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 and why?
-Original Message
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
[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
, 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
really admire them for the constructive way they use header files
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
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 3.3.0 so
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
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 schema change occurred
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 have
[EMAIL PROTECTED] wrote:
What about this change? Is it a worth-while tradeoff?
Personally, I would like to see both of these changes.
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.
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.
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
:-) 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
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
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
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
- 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
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
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
-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:
It's 100,000 more memory
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
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
48 matches
Mail list logo
