libgda issueshttps://gitlab.gnome.org/GNOME/libgda/-/issues2020-07-28T13:10:51Zhttps://gitlab.gnome.org/GNOME/libgda/-/issues/220sqlite3: Add support to bigint type2020-07-28T13:10:51ZPavlo Solntsevsqlite3: Add support to bigint typeCurently, SQLite3 doesn't read correctly very large numbers of type `bigint`. This is because, `SQLite3` doesn't recognize `bigint` type.Curently, SQLite3 doesn't read correctly very large numbers of type `bigint`. This is because, `SQLite3` doesn't recognize `bigint` type.6.0Pavlo SolntsevPavlo Solntsevhttps://gitlab.gnome.org/GNOME/libgda/-/issues/128storage size of ‘hctx’ isn’t known2019-07-30T19:32:13ZBugzillastorage size of ‘hctx’ isn’t known## Submitted by Pavlo Solntsev `@pavlosun`
Assigned to **mal..@..db.org**
**[Link to original bug (#781832)](https://bugzilla.gnome.org/show_bug.cgi?id=781832)**
## Description
Can't compile master via jhbuild (Debian testing up t...## Submitted by Pavlo Solntsev `@pavlosun`
Assigned to **mal..@..db.org**
**[Link to original bug (#781832)](https://bugzilla.gnome.org/show_bug.cgi?id=781832)**
## Description
Can't compile master via jhbuild (Debian testing up to date):
```
CC sqlcipher.gresources.lo
sqlite3.c: In function ‘sqlcipher_openssl_hmac’:
sqlite3.c:17150:12: error: storage size of ‘hctx’ isn’t known
HMAC_CTX hctx;
^~~~
sqlite3.c:17152:3: warning: implicit declaration of function ‘HMAC_CTX_init’ [-Wimplicit-function-declaration]
HMAC_CTX_init(&hctx);
^~~~~~~~~~~~~
sqlite3.c:17157:3: warning: implicit declaration of function ‘HMAC_CTX_cleanup’ [-Wimplicit-function-declaration]
HMAC_CTX_cleanup(&hctx);
^~~~~~~~~~~~~~~~
sqlite3.c: In function ‘sqlcipher_openssl_cipher’:
sqlite3.c:17167:18: error: storage size of ‘ectx’ isn’t known
EVP_CIPHER_CTX ectx;
^~~~
Makefile:675: recipe for target 'sqlite3.lo' failed
```
Thanks.
Version: 5.2.x5.4.0https://gitlab.gnome.org/GNOME/libgda/-/issues/88check_vcnc test fails when building against sqlite 3.112018-10-08T22:41:00ZBugzillacheck_vcnc test fails when building against sqlite 3.11## Submitted by Robie Basak
Assigned to **mal..@..db.org**
**[Link to original bug (#764860)](https://bugzilla.gnome.org/show_bug.cgi?id=764860)**
## Description
Created attachment 325680
Test failure logged in tests/data-models/
...## Submitted by Robie Basak
Assigned to **mal..@..db.org**
**[Link to original bug (#764860)](https://bugzilla.gnome.org/show_bug.cgi?id=764860)**
## Description
Created attachment 325680
Test failure logged in tests/data-models/
When building against sqlite 3.11, the check_vcnc test fails with:
ERROR:gda-vprovider-data-model.c:1316:map_sqlite3_info_to_gda_filter: code should not be reached
FAIL check_vcnc (exit status: 134)
Based on a core dump, this corresponds to a g_assert_not_reached call made from map_sqlite3_info_to_gda_filter. In switch(info->aConstraint[i].op), op corresponds to SQLITE_INDEX_CONSTRAINT_LIKE and this is not implemented.
Implementing it fixes the problem and I'll attach a patch.
I'd like some advice though. Based on this analysis, is it acceptable to not implement the other two SQLITE_INDEX_CONSTRAINT_REGEXP and SQLITE_INDEX_CONSTRAINT_GLOB constraints? Or does this mean that some set of queries will fail?
It looks like we'll be releasing Ubuntu 16.04 in a couple of weeks with this patch since we fail to build against sqlite 3.11 to which we've already updated, so I'd appreciate your advice on whether this is acceptable.
Thanks!
From 0822e61b4e56131aa9ee08bf0239ec6d2efa92b1 Mon Sep 17 00:00:00 2001
From: Robie Basak <robie.basak@canonical.com>
Date: Sun, 10 Apr 2016 19:03:00 +0000
Subject: [PATCH 1/1] Accept SQLITE_INDEX_CONSTRAINT_LIKE from sqlite
sqlite 3.10.0 added the SQLITE_INDEX_CONSTRAINT_LIKE,
SQLITE_INDEX_CONSTRAINT_GLOB and SQLITE_INDEX_CONSTRAINT_REGEXP
constraint operators to the list that xBestIndex can be supplied. See
https://www.sqlite.org/vtab.html for details.
Compiling against sqlite 3.11 (the current version in Ubuntu Xenial and
Debian stretch) causes a build failure because sqlite supplies
SQLITE_INDEX_CONSTRAINT_LIKE and libgda's implementation of xBestIndex
cannot understand it:
ERROR:gda-vprovider-data-model.c:1316:map_sqlite3_info_to_gda_filter: code should not be reached
FAIL check_vcnc (exit status: 134)
Since libgda already defines (and thus presumably implements)
GDA_SQL_OPERATOR_TYPE_LIKE, update the sqlite virtual provider to use
it.
With this change, libgda5 5.2.4 builds and passes tests again when built
against sqlite 3.11. However it may be necessary to implement
SQLITE_INDEX_CONSTRAINT_GLOB and SQLITE_INDEX_CONSTRAINT_REGEXP also to
cover all possible queries.
Though not necessary for Debian or Ubuntu, it may be necessary to make
this change conditional on >= 3.10 if it is required that builds against
older sqlite versions are still possible.
---
libgda/sqlite/virtual/gda-vprovider-data-model.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libgda/sqlite/virtual/gda-vprovider-data-model.c b/libgda/sqlite/virtual/gda-vprovider-data-model.c
index 0393eaf..d966ab1 100644
--- a/libgda/sqlite/virtual/gda-vprovider-data-model.c
+++ b/libgda/sqlite/virtual/gda-vprovider-data-model.c
@@ -1355,6 +1355,9 @@ map_sqlite3_info_to_gda_filter (sqlite3_index_info *info, GdaVconnectionDataMode
case SQLITE_INDEX_CONSTRAINT_MATCH:
filter->aConstraint[j].op = GDA_SQL_OPERATOR_TYPE_REGEXP;
break;
+ case SQLITE_INDEX_CONSTRAINT_LIKE:
+ filter->aConstraint[j].op = GDA_SQL_OPERATOR_TYPE_LIKE;
+ break;
default:
g_assert_not_reached ();
}
--
2.5.0
**Attachment 325680**, "Test failure logged in tests/data-models/":
[test-suite.log](/uploads/33344062bb9706fb675199adab987503/test-suite.log)
Version: 5.2.xGDA 5.99.90https://gitlab.gnome.org/GNOME/libgda/-/issues/86int64 (aka bigint) is not supported2018-09-21T20:09:31ZBugzillaint64 (aka bigint) is not supported## Submitted by Lucas Baudin
Assigned to **mal..@..db.org**
**[Link to original bug (#759792)](https://bugzilla.gnome.org/show_bug.cgi?id=759792)**
## Description
libgda does not seem to be able to understand values bigger than 2^...## Submitted by Lucas Baudin
Assigned to **mal..@..db.org**
**[Link to original bug (#759792)](https://bugzilla.gnome.org/show_bug.cgi?id=759792)**
## Description
libgda does not seem to be able to understand values bigger than 2^31. Using the vala example [1] with a database containing a BIGINT column, it only displays
### instead of actual numbers (numbres < 2^31 work fine). With the gda browser, I get some 0 (which is wrong). It works fine with sqlite3 directly, or with sqliteman.
[1] https://wiki.gnome.org/Projects/Vala/GDAhttps://gitlab.gnome.org/GNOME/libgda/-/issues/49last_insert_rowid's performance is bad.2018-10-10T17:51:42ZBugzillalast_insert_rowid's performance is bad.## Submitted by Massimo Cora'
Assigned to **mal..@..db.org**
**[Link to original bug (#623891)](https://bugzilla.gnome.org/show_bug.cgi?id=623891)**
## Description
After so much benchmarking and hacking on symbol-db population flo...## Submitted by Massimo Cora'
Assigned to **mal..@..db.org**
**[Link to original bug (#623891)](https://bugzilla.gnome.org/show_bug.cgi?id=623891)**
## Description
After so much benchmarking and hacking on symbol-db population flow trying to understand why it was so slow, I probably found the reason.
last_insert_rowid information retrieved with a gda_connection_statement_execute_non_select () statement is the bottle neck.
When libgda retrieves last_insert_rowid information it becomes 10x times slower than SQLite native apis! 7.70 vs 0.80
When the sqlite3_last_insert_rowid (db) is used on sqlite side it's performance grows up only for some milliseconds, but outperforms libgda in any case.
Please check the benchmark programs here
http://git.gnome.org/browse/anjuta/tree/plugins/symbol-db/benchmark/libgda?h=sdb-core-trans
and
http://git.gnome.org/browse/anjuta/tree/plugins/symbol-db/benchmark/sqlite?h=sdb-core-trans
to have some tests.
you don't need to compile Anjuta to have them working, you can just compile them out of the box.
Version: 4.1.x
### Blocking
* [Bug 565773](https://bugzilla.gnome.org/show_bug.cgi?id=565773)GDA 7.0