Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
[EMAIL PROTECTED] wrote: "Shane Harrelson" <[EMAIL PROTECTED]> wrote: This allowed me to get the benefits of the single source file (more compiler optimizations, etc.) while keeping the manageability, etc. of the separate source file. I'm still having trouble trying to understand how managing 60 separate code files is perceived to be easier than managing just 2 files (sqlite3.c and sqlite3.h). It seems to me that the management problem gets much easier the fewer files there are to manage. I know that for my own projects, the use of the amalgamation has greatly simplified configuration management. Now I have just two files (sqlite3.[ch]) that I drop into my project and I'm done. Before I had to either create an external dependency on a external SQLite library and manage that, or import 60+ code files in to a subdirectory with its own makefile, etc. What a pain. Chris Peachment points out that his "Pelles C" compiler (never heard of that one before, but presumably it has its purposes) is unable to compile sqlite3.c, presumably because the file is is too large. This is the only reason I have heard yet for wanting to use separate source file that makes any sense to me. Can somebody please explain to my how 2 files is less manageable than 60? Having multiple files means that there is sub-division of purpose. If there is known to be a problem with the function handling then one can find the code in func.c. Recompilation times can be considerably less if changes can be isolated to 1 file out of 60, with the remaining 59 being unchanged and therefore not requiring recompilation. With an amalgamation, one is forced to recompile the entire project for any single change. I would have thought that if you were so convinced that the reduced numbers of files were easier then you would have abandoned the distribution which used 60 files entirely, and switched to developing with just the 2 files. That you have not leads me to think that you find the 60 files more manageable than 2. In your example above you've cited that dropping a pair of files on to your project has made things easier for you. I don't doubt this and I quite agree. Personally I feel that having a dependency on a library is far more desireable for a project, rather than direct inclusion of the source, but that's a build issue, rather than a distribution issue. However, the point you're making is from a black-box user's point of view. The user doesn't care how it works or what it does, but just that it does what they want. Other users - those who don't treat it as a black box and wish to extend functionality or develop more usefully from the code base, and those who are (because of the environment they must work in) forced to make changes to the sources - are far more comfortable with a distribution that contains multiple files split up as a developer might want to work with. I would have said that there is scope for the 3 different forms of distribution : * The base distribution that is used for users who can run the parser. * The pre-processed distribution, as before, for those users who wish to work with the sources, but don't necessarily want to (or are unable to, because of their environment) run the parser. * The amalgamation distribution, as we have now, for those users who treat the database as a black-box and never wish to know any more than that it compiled and works. -- Justin Fletcher, Senior Software Engineer Picsel Technologies Ltd Tel: +44 141 8855588 Titanium House, Kings Inch Rd, Glasgow, G51 4BP, UK Web: www.picsel.com This email is subject to disclaimer at http://www.picsel.com/disclaimer.html - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] changes() function discrepancy
Hiya, I'm examining the test suite and I'm trying to reproduce the results for test laststmtchanges-1.1 (and friends). This test creates and populates a small database as follows : create table t0 (x); insert into t0 values (1); insert into t0 values (1); insert into t0 values (2); insert into t0 values (2); insert into t0 values (1); insert into t0 values (1); insert into t0 values (1); insert into t0 values (2); select changes(), total_changes(); It then expects back results of "1 8" because the last insert operated on a single row (that is, exposing sqlite3_changes()) and because the total number of changes to the database is 8 (exposing sqlite3_total_changes()). In my own code the sequence generates "2 8". I've tried reproducing the sequence in the shell and I get a curious result. A copy of my attempts to reproduce the problem follows : 8< [EMAIL PROTECTED]:~/sqlite-3.3.16$ ./sqlite3 temp.db SQLite version 3.3.16 Enter ".help" for instructions sqlite> create table t0 (x); sqlite> insert into t0 values(1); sqlite> select changes(), total_changes(); 1|1 sqlite> .quit [EMAIL PROTECTED]:~/sqlite-3.3.16$ rm temp.db [EMAIL PROTECTED]:~/sqlite-3.3.16$ ./sqlite3 temp.db SQLite version 3.3.16 Enter ".help" for instructions sqlite> create table t0 (x); sqlite> insert into t0 values(1); select changes(), total_changes(); 2|1 8< The second of these two results shows that the values of changes() may exceed the total number of changes made which seems odd in its own right. From my own experiments changes() appears to be double the expected value when it is used in the second form, for example : 8< sqlite> create table t0 (x); sqlite> insert into t0 values (1); sqlite> insert into t0 values (1); sqlite> insert into t0 values (2); sqlite> insert into t0 values (2); sqlite> insert into t0 values (1); sqlite> insert into t0 values (1); sqlite> insert into t0 values (1); sqlite> insert into t0 values (2); sqlite> sqlite> update t0 set x=9 where x=1; select changes(), total_changes(); 10|13 8< Is there a reason for this seeming discrepancy in the execution of the changes function ? -- Justin Fletcher, Senior Software Engineer Picsel Technologies Ltd Tel: +44 141 8855588 Titanium House, Kings Inch Rd, Glasgow, G51 4BP, UK Web: www.picsel.com This email is subject to disclaimer at http://www.picsel.com/disclaimer.html - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem with understanding the test suite
[EMAIL PROTECTED] wrote:
Justin Fletcher <[EMAIL PROTECTED]> wrote:
do_test select1-11.2.2 {
execsql2 {
SELECT * FROM t3, t4;
}
} {a 3 b 4 a 3 b 4}
Can someone explain how the test can be correct ?
This comes about because of duplicate column names.
The execsql2 procedure looks at all column names in
the result set, then returns the value associated with
each column name. So in the example above, it looks
at columns named "a", "b", "a", and "b", in that order.
But both "a" and "b" are ambiguous names. So it picks
the value that corresponds to the column that is last
in the list.
This is goofy, perhaps, but it is the way the test
system works.
That's good because it means that I'm not going crazy -
thanks :-)
As test select1-11.2.1 already produced a useful result
for this class of test and 11.2.2 provides no additional
tests, it is probably redundant as a test there - the
test it's performing is actually being obscured by the
goofy test system :-|
I'm working my way through the test suite and will need
to identify such cases. Would it be useful to report these
in order that they can be flagged as being obscured by the
test system ?
--
Justin Fletcher, Senior Software Engineer
Picsel Technologies Ltd Tel: +44 141 8855588
Titanium House, Kings Inch Rd, Glasgow, G51 4BP, UK Web: www.picsel.com
This email is subject to disclaimer at http://www.picsel.com/disclaimer.html
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] Problem with understanding the test suite
Hi,
I'm doing some work with the SQLite test suite and I'm confused as to the
purpose or correctness of a couple of the tests. A few tests have shown
up odd issues, but the following is typical of the general case.
8<
do_test select1-11.1 {
execsql {
DELETE FROM t3;
DELETE FROM t4;
INSERT INTO t3 VALUES(1,2);
INSERT INTO t4 VALUES(3,4);
SELECT * FROM t3, t4;
}
} {1 2 3 4}
do_test select1-11.2.1 {
execsql {
SELECT * FROM t3, t4;
}
} {1 2 3 4}
do_test select1-11.2.2 {
execsql2 {
SELECT * FROM t3, t4;
}
} {a 3 b 4 a 3 b 4}
8<
My understanding of these descriptions is that ...
'do_test '
- Runs the code in and compares its results to .
This is collectively known as test .
'execsql '
- Runs the SQL in and accumulates the results in a list,
each column's results being appended to the results. Row boundaries
are ignored.
'execsql2 '
- As execsql, above, but precedes each value by the name of the column.
This is similar to '.mode line' at the SQL command line.
Test select1-11.1, above, populates two tables with values. The first has
the a row with 2 columns, containing 1,2; the second has a row with 2
columns containing 3,4. It then selects the values from these. The result,
'1 2 3 4' matches the expected result.
Test select1-11.2.1 selects all elements from the list, as above. Again,
it produces the expected results '1 2 3 4'.
Test select1-11.2.2 is the test I have a problem with. The same command is
used, but is expected to precede each column with the column name. I expect
the result to be 'a 1 b 2 a 3 b 4'. The test suite expects (and gets)
'a 3 b 4 a 3 b 4'.
Either this means that my understanding of execsql2 is wrong, or the test
suite is incorrectly testing for this case.
To be a little clearer, I equate the final test to the following sequence
in the sqlite command line :
sqlite> CREATE TABLE t3(a,b);
sqlite> CREATE TABLE t4(a,b);
sqlite> .mode line
sqlite> SELECT * FROM t3,t4;
sqlite> INSERT INTO t3 VALUES(1,2);
sqlite> INSERT INTO t4 VALUES(3,4);
sqlite> SELECT * FROM t3,t4;
a = 1
b = 2
a = 3
b = 4
sqlite>
Can someone explain how the test can be correct ?
The execsql2 function in tester.tcl is as follows :
8<
# Another procedure to execute SQL. This one includes the field
# names in the returned list.
#
proc execsql2 {sql} {
set result {}
db eval $sql data {
foreach f $data(*) {
lappend result $f $data($f)
}
}
return $result
}
8<
My understanding of TCL is very very rough, but I believe that the loop
'foreach f $data(*)' loops over every column name and prepends the column
name to those values in the result string. As the column names match in
the results, I think that gives the strange results.
--
Justin Fletcher, Senior Software Engineer
Picsel Technologies Ltd Tel: +44 141 8855588
Titanium House, Kings Inch Rd, Glasgow, G51 4BP, UK Web: www.picsel.com
This email is subject to disclaimer at http://www.picsel.com/disclaimer.html
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
