[sqlite] Re: my own fixes for symbol conflict - encode.c
At 5:25 AM +0100 9/13/04, Matt Sergeant wrote: I don't think encode.c is part of sqlite3 - it certainly isn't relevant now sqlite has proper blob support. I suspect it got left in DBD::SQLite as a remnant of the previous version. That same file is in the 3.0.6 source tarball on the sqlite.org website ( http://sqlite.org/sqlite-3.0.6.tar.gz ); I checked, and that file is identical to the copy in DBD-SQLite 1.05, except for the date stamp inside. That said, the original date stamp was from March or April of 2004, so it may not be used. If what you are saying is true, that it's not part of SQLite 3, then it should be removed from the main SQLite 3 CVS tree, and source tarball. For that matter, there should be an investigation in case any other files in there should be dropped too. Dropping unused-and-not-to-be-used code is good prior to a 'generally available' release, cutting the disk/ram footprint down. What say you, Richard? -- Darren Duncan
[sqlite] Re: my own fixes for symbol conflict - encode.c
On Sun, 12 Sep 2004, Darren Duncan wrote: > Following the application of Matt Sergeant's diffs, I still had some > similar problems. But this time, seeing what kinds of things he > changed, I tracked down and fixed the problems myself. > > Below this letter is the diff of my changes, which when used in > addition to Matt's, allowed me to use SQLite2 and SQLite3 together > (for that test anyway) under Mac OS X 10.2.8. > > This change is in the SQLite core, the file "encode.c" to be > specific, so someone with commit privileges on sqlite.org will have > to apply it. > > In summary, I renamed all occurances of > sqlite_[encode|decode]_binary() to sqlite3_[encode|decode]_binary() > in "encode.c". I don't think encode.c is part of sqlite3 - it certainly isn't relevant now sqlite has proper blob support. I suspect it got left in DBD::SQLite as a remnant of the previous version. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
[sqlite] my own fixes for symbol conflict - encode.c
Following the application of Matt Sergeant's diffs, I still had some
similar problems. But this time, seeing what kinds of things he
changed, I tracked down and fixed the problems myself.
Below this letter is the diff of my changes, which when used in
addition to Matt's, allowed me to use SQLite2 and SQLite3 together
(for that test anyway) under Mac OS X 10.2.8.
This change is in the SQLite core, the file "encode.c" to be
specific, so someone with commit privileges on sqlite.org will have
to apply it.
In summary, I renamed all occurances of
sqlite_[encode|decode]_binary() to sqlite3_[encode|decode]_binary()
in "encode.c".
FYI, assuming this is accepted into the core (or you can easier redo
it yourself with a quick search-n-replace), it will mark the first
time I actually ever edited and returned changes to the SQLite core,
which to me is special. (And yes, I commit it to the public domain.)
Hopefully this will make it into SQLite 3.0.7, and a corresponding
DBD::SQLite 1.06.
-- Darren Duncan
[S0106000393c33758:/Volumes/Programming/DBD-SQLite-1.05]
darrenduncan% diff encode.c encode-DARREN.c
107c107
< ** or UPDATE statement. Use sqlite_decode_binary() to convert the
---
> ** or UPDATE statement. Use sqlite3_decode_binary() to convert the
123c123
< int sqlite_encode_binary(const unsigned char *in, int n,
unsigned char *out){
---
> int sqlite3_encode_binary(const unsigned char *in, int n,
unsigned char *out){
167c167
< ** This routine reverses the encoding created by
sqlite_encode_binary().
---
> ** This routine reverses the encoding created by
sqlite3_encode_binary().
175c175
< int sqlite_decode_binary(const unsigned char *in, unsigned
char *out){
---
> int sqlite3_decode_binary(const unsigned char *in, unsigned
char *out){
216c216
< nOut = sqlite_encode_binary(in, n, out);
---
> nOut = sqlite3_encode_binary(in, n, out);
222c222
< if( nOut!=sqlite_encode_binary(in, n, 0) ){
---
> if( nOut!=sqlite3_encode_binary(in, n, 0) ){
238c238
< j = sqlite_decode_binary(out, out);
---
> j = sqlite3_decode_binary(out, out);
Re: [sqlite] No data with PRAGMA table_info
EzTools Support, dando pulos de alegria, escreveu : Sorry, I meant for 3.x. Does it work for anyone? No problems here with 3.0.6. Regards, ~Nuno Lucas
Re: [sqlite] No data with PRAGMA table_info
Sorry, I meant for 3.x. Does it work for anyone? try IeToolbox Passwords & Notes Keeper, Form Filler and much more www.ietoolbox.com [EMAIL PROTECTED] wrote: EzTools Support <[EMAIL PROTECTED]> writes: When I issue PRAGMA table_info for an existing table, I get the column names back, but no values. Does it work for anyone else? In 2.8.15, the command pragma table_info(tablename); works as it's intended, returning one row for each column in the table. Each row contains the cid, name, type, notnull, dflt_value and pk values. Derrell
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
At 11:02 AM +0100 9/12/04, Matt Sergeant wrote: On Sun, 12 Sep 2004, Matt Sergeant wrote: > All DBD::SQLite dev is done on OS X (Panther currently). So it should be easy. Ah, ok so Panther fixed the annoying strictness of Jaguar. However I think the following patch should cover all bases: Thank you. I applied those changes and all the install stuff worked. However, there are more outstanding, similar issues: [S0106000393c33758:Documents/Perl Distributions/devworld] darrenduncan% ../perl58 dbd_load_test.pl dyld: ../perl58 multiple definitions of symbol _sqlite_decode_binary /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite/SQLite.bundle definition of _sqlite_decode_binary /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite2/SQLite2.bundle definition of _sqlite_decode_binary Trace/BPT trap So it's good you're running this by me before a CPAN install. BTW, if you *really* can't access your own 10.2.8 machine, then I could probably give you temporary shell access on mine for remote testing. I await the next reply. -- Darren Duncan
Re: [sqlite] No data with PRAGMA table_info
EzTools Support <[EMAIL PROTECTED]> writes: > When I issue PRAGMA table_info for an existing table, I get the column > names back, but no values. Does it work for anyone else? In 2.8.15, the command pragma table_info(tablename); works as it's intended, returning one row for each column in the table. Each row contains the cid, name, type, notnull, dflt_value and pk values. Derrell
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
On Sun, 12 Sep 2004, Matt Sergeant wrote:
> On Sat, 11 Sep 2004, Darren Duncan wrote:
>
> > At 12:49 AM +0100 9/12/04, Matt Sergeant wrote:
> > >This is just because Mac OSX is fussy - Linux won't complain and will let
> > >the latterly loaded symbol supercede. But it's a valid bug in
> > >DBD::SQLite2, so I'll fix it in the next release (should be simple).
> > >Matt.
> >
> > Now, unless you have a Mac OS X box of your own to test against,
> > please send me a copy of the changed source files (the whole files,
> > not diffs) asap, and I'll test your current distro with those
> > changes. This way, if something else comes up, I can have tested
> > that it works good prior to you uploading it to CPAN. I'll be
> > waiting for them. -- Darren Duncan
>
> All DBD::SQLite dev is done on OS X (Panther currently). So it should be
> easy.
Ah, ok so Panther fixed the annoying strictness of Jaguar. However I think
the following patch should cover all bases:
Index: SQLite.xs
===
RCS file: /home/cvs/DBD-SQLite/SQLite.xs,v
retrieving revision 1.6
diff -u -r1.6 SQLite.xs
--- SQLite.xs 2004/07/21 20:50:42 1.6
+++ SQLite.xs 2004/09/12 10:02:30
@@ -37,7 +37,7 @@
SV *func
CODE:
{
-sqlite_db_create_function( dbh, name, argc, func );
+sqlite3_db_create_function( dbh, name, argc, func );
}
void
@@ -48,7 +48,7 @@
SV *aggr
CODE:
{
-sqlite_db_create_aggregate( dbh, name, argc, aggr );
+sqlite3_db_create_aggregate( dbh, name, argc, aggr );
}
int
@@ -56,7 +56,7 @@
SV *dbh
int timeout
CODE:
-RETVAL = sqlite_busy_timeout( dbh, timeout );
+RETVAL = dbd_set_sqlite3_busy_timeout( dbh, timeout );
OUTPUT:
RETVAL
Index: dbdimp.c
===
RCS file: /home/cvs/DBD-SQLite/dbdimp.c,v
retrieving revision 1.50
diff -u -r1.50 dbdimp.c
--- dbdimp.c2004/08/29 10:11:57 1.50
+++ dbdimp.c2004/09/12 10:02:30
@@ -128,7 +128,7 @@
}
int
-sqlite_busy_timeout ( SV *dbh, int timeout )
+dbd_set_sqlite3_busy_timeout ( SV *dbh, int timeout )
{
D_imp_dbh(dbh);
if (timeout) {
@@ -761,7 +761,7 @@
}
void
-sqlite_db_create_function( SV *dbh, const char *name, int argc, SV *func
)
+sqlite3_db_create_function( SV *dbh, const char *name, int argc, SV *func
)
{
D_imp_dbh(dbh);
int rv;
@@ -975,7 +975,7 @@
}
void
-sqlite_db_create_aggregate( SV *dbh, const char *name, int argc, SV
*aggr_pkg )
+sqlite3_db_create_aggregate( SV *dbh, const char *name, int argc, SV
*aggr_pkg )
{
D_imp_dbh(dbh);
int rv;
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
On Sat, 11 Sep 2004, Darren Duncan wrote: > At 12:49 AM +0100 9/12/04, Matt Sergeant wrote: > >This is just because Mac OSX is fussy - Linux won't complain and will let > >the latterly loaded symbol supercede. But it's a valid bug in > >DBD::SQLite2, so I'll fix it in the next release (should be simple). > >Matt. > > Now, unless you have a Mac OS X box of your own to test against, > please send me a copy of the changed source files (the whole files, > not diffs) asap, and I'll test your current distro with those > changes. This way, if something else comes up, I can have tested > that it works good prior to you uploading it to CPAN. I'll be > waiting for them. -- Darren Duncan All DBD::SQLite dev is done on OS X (Panther currently). So it should be easy. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
[sqlite] No data with PRAGMA table_info
When I issue PRAGMA table_info for an existing table, I get the column names back, but no values. Does it work for anyone else? TIA -brett
Re: [sqlite] sqlite.exe binary (windows)
True ... After thinking a while I understood it ;-) Thanks for the explanation. Steven At 16:16 9/09/2004, you wrote: On Thu, 9 Sep 2004, Steven Van Ingelgem wrote: >I just noticed something rather stupid... > >when you .dump a table via the sqlite.exe binary (2.8.15)... It dumps first >the "create table", then the "insert"s, and afterwards the indexes > >Now if you have a very big table it will take a LOT of time to place those >indexes... Maybe it is more performant to place the "create index" just >after the "create table" statement? Try benchmarking it yourself. You'll probably find that it is in fact quicker to insert the data without indexes, and then index. This is because indexing isn't free. It impacts insert and potentially update performance, as the index may also have to be updated with each update, and will certainly need to be updated with each insert. A quick test (374245 rows, single column with index.) With the index created after the inserts: $ cat test.dump.1 | time -p sqlite test.1 real 22.67 user 17.59 sys 1.27 With index created before the inserts: $ cat test.dump.2 | time -p sqlite test.2 real 24.17 user 18.99 sys 1.50 Repeated the test with similar results, so the post-indexing is about 1.5 seconds quicker in this case. > >Greetings, > >KaReL (aka Steven) > Christian -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ pgpue5sOZYMKU.pgp Description: PGP signature
