Re: [sqlite] Unsigned
The original question was that I was curious about the history. Noting where we are now at, I will give as examples of two real world applications: 1. 32 bit embedded sqlite. Realtime storing data from various hardware interfaces. The data includes unsigned 32 bit integers which are stored as float (don't ask me why, I guess the primary reason is the same reason that 32bit Lua uses floats as integers). There is heavy (unsigned) arithmetic computation at database read/write time. The application is stable. The maintainers/developers rue the additional code because of sqlite and no native unsigned type. They have a historic codebase for 3 other database systems which they have previously used. 2. Mixed 64/32 bit system that has integers that use the full 64 bits. Numbers are sourced by realtime hardware. Absence of 64 bit unsigned means addition of few functions to handle inserts and display representation(s), numbers stored as text/blobs. Again this all works, just extra code and indexes are less than optimum (compared to previous used mysql). ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Next release
Roger Schlueter wrote: > > What about System.Data.SQLite? > I would estimate that the next System.Data.SQLite release, which will include SQLite 3.25, will be released within two to three weeks after SQLite 3.25 itself is released, barring an unforeseen complications. -- Joe Mistachkin ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Next release
What about System.Data.SQLite? On 8/25/2018 13:04, Richard Hipp wrote: On 8/25/18, R Smith wrote: A quick dev question: Any idea on the eta for the next release? My best guess at the moment is 4 or 5 weeks. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Next release
On 8/25/18, R Smith wrote: > A quick dev question: Any idea on the eta for the next release? My best guess at the moment is 4 or 5 weeks. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Next release
A quick dev question: Any idea on the eta for the next release? Reason for asking: We're planning a DB tool release soon and can release omitting the Windowing functions, or if it's going to arrive soon, simply wait a bit and include it. This answer, even if vague, will help us make that decision. Thank you kindly, Ryan ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] minor documentation flaw
Thanks. The fix is checked in and will appear in the next release. On 8/25/18, Wolfgang Enzinger wrote: > > In https://sqlite.org/lang_expr.html, the anchor > > > > appears twice. Obviously the second occurence should be > > > > Wolfgang > > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] RBU conflicts with SQLITE_UNTESTABLE
On 8/25/18, Ralf Junker wrote: > I am aware that the use of SQLITE_UNTESTABLE is discouraged. Still I > want to point developers to the fact that SQLITE_UNTESTABLE breaks RBU. Thank you, Ralf. We are well aware of this. There are lots of similar situations, where omitting features from SQLite will break extensions that depend on those features. For example SQLITE_OMIT_VIRTUALTABLE will break FTS3, FTS4, FTS5, and RTREE, all of which depend on virtual tables. We are curious to know, though, what you are doing with RBU? That's a obscure and special purpose extension that we did for a single client. Are you finding it useful for something? -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] minor documentation flaw
In https://sqlite.org/lang_expr.html, the anchor appears twice. Obviously the second occurence should be Wolfgang ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] RBU conflicts with SQLITE_UNTESTABLE
I am aware that the use of SQLITE_UNTESTABLE is discouraged. Still I
want to point developers to the fact that SQLITE_UNTESTABLE breaks RBU.
In particular, RBU relies on SQLITE_TESTCTRL_IMPOSTER to be fully
working. With SQLITE_UNTESTABLE defined, this is not the case. RBU
functions return errors not related to the problem. The target database
is not properly updated.
The C code below demonstrates this. It is based on rbusplit.test
(https://www.sqlite.org/src/artifact/69271c790732b28b).
To see the problem, compile with the C preprocessor directive
SQLITE_UNTESTABLE=1 #defined. Tested with MS Visual Studio 2017.
Ralf
--
#include
#include
#include "sqlite3.h"
#include "sqlite3rbu.h"
sqlite3 *db;
static void check(int r, int e) {
if (r != e) {
printf("ERROR %d %s\n", e, sqlite3_errmsg(db));
}
}
static int callback(void *user, int nCol, char **r, char **c) {
int i;
for (i = 0; i < nCol; i++) {
printf("%s ", r[i]);
}
printf("\n");
return 0;
}
#define rbu_db"rbu.db"
#define target_db "target.db"
int main(void)
{
int r;
sqlite3rbu *rbu;
char *zError;
// Create rbu_db
remove(rbu_db);
check(SQLITE_OK, sqlite3_open_v2(rbu_db, ,
SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, NULL));
check(SQLITE_OK, sqlite3_exec(db,
"BEGIN;" \
"CREATE TABLE data0_t1(a, b, c, rbu_control);" \
"CREATE TABLE data1_t1(a, b, c, rbu_control);" \
"CREATE TABLE data2_t1(a, b, c, rbu_control);" \
"CREATE TABLE data3_t1(a, b, c, rbu_control);" \
"CREATE TABLE data_t2(a, b, c, rbu_control);" \
"INSERT INTO data0_t1 VALUES(1, 1, 1, 0);" \
"INSERT INTO data0_t1 VALUES(2, 2, 2, 0);" \
"INSERT INTO data0_t1 VALUES(3, 3, 3, 0);" \
"INSERT INTO data0_t1 VALUES(4, 4, 4, 0);" \
"INSERT INTO data1_t1 VALUES(5, 5, 5, 0);" \
"INSERT INTO data1_t1 VALUES(6, 6, 6, 0);" \
"INSERT INTO data1_t1 VALUES(7, 7, 7, 0);" \
"INSERT INTO data1_t1 VALUES(8, 8, 8, 0);" \
"INSERT INTO data3_t1 VALUES(9, 9, 9, 0);" \
"INSERT INTO data_t2 VALUES(1, 1, 1, 0);" \
"INSERT INTO data_t2 VALUES(2, 2, 2, 0);" \
"INSERT INTO data_t2 VALUES(3, 3, 3, 0);" \
"INSERT INTO data_t2 VALUES(4, 4, 4, 0);" \
"INSERT INTO data_t2 VALUES(5, 5, 5, 0);" \
"INSERT INTO data_t2 VALUES(6, 6, 6, 0);" \
"INSERT INTO data_t2 VALUES(7, 7, 7, 0);" \
"INSERT INTO data_t2 VALUES(8, 8, 8, 0);" \
"INSERT INTO data_t2 VALUES(9, 9, 9, 0);" \
"COMMIT;",
callback, NULL, NULL));
check(SQLITE_OK, sqlite3_close(db));
// Create target.db
remove(target_db);
check(SQLITE_OK, sqlite3_open_v2(target_db, ,
SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, NULL));
check(SQLITE_OK, sqlite3_exec(db,
"CREATE TABLE t1(a PRIMARY KEY, b, c);"
"CREATE TABLE t2(a PRIMARY KEY, b, c);" \
"CREATE INDEX t1c ON t1(c);",
callback, NULL, NULL));
check(SQLITE_OK, sqlite3_close(db));
// Apply RBU.
rbu = sqlite3rbu_open(target_db, rbu_db, NULL);
do
r = sqlite3rbu_step(rbu);
while (r == SQLITE_OK);
check(SQLITE_DONE, r);
r = sqlite3rbu_close(rbu, );
check(SQLITE_DONE, r);
if (zError) {
printf("%s\n", zError);
sqlite3_free(zError);
}
printf("Done - Press ENTER to exit.");
_getch();
return 0;
}
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Unsigned
On 2018-08-24 11:58 PM, Thomas Kurz wrote: What is the value of a built-in UNSIGNED type when we already have INTEGER? I can't think of any. -- Darren Duncan Signed integers only allow half the range of values of unsigned ones. You cannot store a pointer value in them. (You can by casting to signed, but then sorting is done wrong.) I fully agree with what others have said, which is that this use case is better handled by supporting an unlimited precision integer type. All the "unsigned" request argues for is a single extra bit of precision for positive integers, which is like nit-picking; in practice if you can't fit all the integers you care about in a typical signed machine integer then the unlimited type is the only reasonable step up, for practical purposes. -- Darren Duncan ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Unsigned
> What is the value of a built-in UNSIGNED type when we already have INTEGER? > I can't think of any. -- Darren Duncan Signed integers only allow half the range of values of unsigned ones. You cannot store a pointer value in them. (You can by casting to signed, but then sorting is done wrong.) ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
