Re: [sqlite] Confused with type mismatch in Tcl interface
On 2/28/19, Jean-Baptiste Gardette wrote: > > PS : on wich OS did you run the test script ? > (the different outputs between the two computers gives > unconfortable feeling) > Linux -- 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] Confused with type mismatch in Tcl interface
Sorry for my late reply. Yes, your proposal would definitively solve our problem. (our Tcl dictionnaries are allways filled with values sharing the same type) PS : on wich OS did you run the test script ? (the different outputs between the two computers gives unconfortable feeling) Thank you again Jean-Baptiste --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Confused with type mismatch in Tcl interface
On 2/27/19, Peter da Silva wrote:
> One nasty thing you might be able to do in the interim is to shimmer the
> object to the type you want by doing something like [set x [expr {double
> $x}]] to make it double.
The new optional -returntype TYPE option is now available on the
SQLite trunk. The argument can be one of "integer", "real", "text",
"blob", or "any". The "any" is the default and means that SQLite will
use the Tcl_Obj.typePtr to guess at an appropriate type.
--
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] Confused with type mismatch in Tcl interface
One nasty thing you might be able to do in the interim is to shimmer the
object to the type you want by doing something like [set x [expr {double
$x}]] to make it double.
On Wed, Feb 27, 2019 at 9:31 AM Richard Hipp wrote:
> On 2/27/19, Jean-Baptiste Gardette wrote:
> > have you any explanation why the typof() output of
> > "SELECT DerefDict_SQL('A'), typeof(DerefDict_SQL('A'))"
> > gives "text" in Sequence A and "real" in Sequence B ?
> >
>
> No.
>
> The code that determines the return type of a TCL UDF is here:
> https://www.sqlite.org/src/artifact/6b19e7562195aaf8?ln=993-1018
>
> As you can see, the interface is looking at the Tcl_Obj.typePtr value
> to try to guess an appropriate return type. This is considered bad
> form in TCL since TCL makes no guarantees about the value of typePtr
> for a Tcl_Obj. But the technique has worked well for nearly two
> decades.
>
> What if we were to add a new option to the "db function" method of the
> TCL interface that let you specify the return type of the
> TCL-implemented UDF? If the optional argument is omitted, then the
> current behavior of trying to guess the return type based on typePtr
> is used. But if the "-returntype TYPE" argument is present, it
> determines which return type to use regardless of the value in the
> typePtr. Would that help your situation?
>
> Note that my tests were run after compiling both TCL and SQLite from
> sources. There is no telling what non-standard changes may have been
> added by people who assembled your pre-compiled binaries.
>
>
>
> --
> 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-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Confused with type mismatch in Tcl interface
On 2/27/19, Jean-Baptiste Gardette wrote:
> have you any explanation why the typof() output of
> "SELECT DerefDict_SQL('A'), typeof(DerefDict_SQL('A'))"
> gives "text" in Sequence A and "real" in Sequence B ?
>
No.
The code that determines the return type of a TCL UDF is here:
https://www.sqlite.org/src/artifact/6b19e7562195aaf8?ln=993-1018
As you can see, the interface is looking at the Tcl_Obj.typePtr value
to try to guess an appropriate return type. This is considered bad
form in TCL since TCL makes no guarantees about the value of typePtr
for a Tcl_Obj. But the technique has worked well for nearly two
decades.
What if we were to add a new option to the "db function" method of the
TCL interface that let you specify the return type of the
TCL-implemented UDF? If the optional argument is omitted, then the
current behavior of trying to guess the return type based on typePtr
is used. But if the "-returntype TYPE" argument is present, it
determines which return type to use regardless of the value in the
typePtr. Would that help your situation?
Note that my tests were run after compiling both TCL and SQLite from
sources. There is no telling what non-standard changes may have been
added by people who assembled your pre-compiled binaries.
--
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] Confused with type mismatch in Tcl interface
Le 27/02/2019 à 14:55, Richard Hipp a écrit :
On 2/27/19, Richard Hipp wrote:
The modified script can be downloaded from
https://sqlite.orge/tmp/tcl-sqlite-testcase-20190227125331.txt
Typo: "sqlite.org", not "sqlite.orge".
https://sqlite.org/tmp/tcl-sqlite-testcase-20190227125331.txt
Thank Mr Hipp, for your script
Platform here : Win 7 + SQLite 3.24.0 + Tcl 8.6.9
Additional precisions :
- Tcl provided by Magicsplat latest version (1.9.0)
(https://www.magicsplat.com/tcl-installer/index.html)
- SQLite package provided by AndroWish release "Asteroid Day"
vanilla distribution (http://www.androwish.org/download/index.html)
because we need JSON extension (absent from Magicsplat)
I ran your script and I didn't get same results as yours.
Here below are results from your script runed on my computer,
unchanged from my first post :
8.6
8.6.9
{2018-06-04 19:24:41
c7ee0833225bfd8c5ec2f9bf62b97c4e04d03bd9566366d5221ac8fb199a87ca}
# Sequence A
1.00
1.00 text
1.00 text
1.00 text
1.00 blob
1 real
# Sequence B
1.00
1.0 real
1.0 real
1.0 real
1.00 blob
1 real
# Sequence C
1.00
1.00 text
1.00 text
1.0 real
1.00 blob
1.0 real
Compared to your output from your computer :
8.6
8.6.9
{2019-02-26 18:21:08
6d39d6a68bf09e0b4f6706218373e74fc03148fd8bdba5031c3de2f750d87cf2}
# Sequence A
1.00
1.00 text
1.00 text
1.00 text
1.00 blob
1.00 text
# Sequence B
1.00
1.0 real
1.0 real
1.0 real
1.00 blob
1.00 text
# Sequence C
1.00
1.00 text
1.00 text
1.00 text
1.00 blob
1.00 text
Apart the unclear reasons the outputs differ between the two computers,
have you any explanation why the typof() output of
"SELECT DerefDict_SQL('A'), typeof(DerefDict_SQL('A'))" (identical in
both compturers)
gives "text" in Sequence A and "real" in Sequence B ?
Thank you
Jean-Baptiste
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Confused with type mismatch in Tcl interface
On 2/27/19, Richard Hipp wrote: > The modified script can be downloaded from > > https://sqlite.orge/tmp/tcl-sqlite-testcase-20190227125331.txt > Typo: "sqlite.org", not "sqlite.orge". https://sqlite.org/tmp/tcl-sqlite-testcase-20190227125331.txt -- 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] Confused with type mismatch in Tcl interface
On 2/26/19, Jean-Baptiste Gardette wrote:
> the type of a value returned by one UDF
> dereferencing a tcl dictionnary : the type is changing depending from
> the context.
I am unable to reproduce the behavior you observe.
I did a copy/paste of your script with simple changes: (1) The "#
Sequence" comments were put inside a "puts" so that they appear in the
output. (2) Version identification was printing at the top of the
script. The modified script can be downloaded from
https://sqlite.orge/tmp/tcl-sqlite-testcase-20190227125331.txt
When I run this script, I get:
8.6
8.6.9
{2019-02-26 18:21:08
6d39d6a68bf09e0b4f6706218373e74fc03148fd8bdba5031c3de2f750d87cf2}
# Sequence A
1.00
1.00 text
1.00 text
1.00 text
1.00 blob
1.00 text
# Sequence B
1.00
1.0 real
1.0 real
1.0 real
1.00 blob
1.00 text
# Sequence C
1.00
1.00 text
1.00 text
1.00 text
1.00 blob
1.00 text
--
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] Confused with type mismatch in Tcl interface
Win 7, SQLite 3.24.0, Tcl 8.6.9
We don't know if it is a problem about SQLite or Tcl, apologies if it
is the wrong list.
Our main concern is the type of a value returned by one UDF
dereferencing a tcl dictionnary : the type is changing depending from
the context.
We observed that a decimal number stored as a string with [format %.2f]
in a dictionnary is sometime understood as string at SQlite level, and
sometime undestood as a real.
Obviously, this lead to serious pb when comparison are done at SQL level.
Below is a script analysing all variations observed on this subject.
It points to different issues, but our main concern is at first about
the UDF.
package require sqlite3
sqlite3 db test
proc DerefDict {key} {
dict get $::tclDict $key
}
db function DerefDict_SQL -deterministic DerefDict
# (please note the -deterministic parameter of the UDF)
set i [format %.2f [expr {1 + 0}]]
dict set tclDict A $i
# Abreviations :
# OK = understood from reading the SQLite doc
# (!) , <- = not understood
# Sequence A
puts [dict get $tclDict A] ;# A1 returns 1.00Reference
puts [db eval {SELECT $i, typeof($i)}] ;# A2 returns 1.00 text OK
puts [db eval "SELECT :i, typeof(:i)"] ;# A3 returns 1.00 text idem as
above
puts [db eval "SELECT DerefDict_SQL('A'),
typeof(DerefDict_SQL('A'))"] ;# A4 returns 1.00 text OK
puts [db eval "SELECT @i, typeof(@i)"] ;# A5 returns 1.00 blob OK
puts [db eval "SELECT DerefDict_SQL('A'),
typeof(DerefDict_SQL('A'))"] ;# A6 returns 1real (!) <-
# Sequence B
if {$i == 0} {}
# Surprisingly, the above test on variable i modifies the type
# of returned values for : and @ operators in SQLite :
puts [dict get $tclDict A] ;# B1 returns 1.00 Reference
puts [db eval {SELECT $i, typeof($i)}] ;# B2 Changed with A : returns
1.0 real <-
puts [db eval "SELECT :i, typeof(:i)"] ;# B3 Changed with A : returns
1.0 real <-
puts [db eval "SELECT DerefDict_SQL('A'),
typeof(DerefDict_SQL('A'))"] ;# B4 Changed with A : returns 1.0
real <-
puts [db eval "SELECT @i, typeof(@i)"] ;# B5 Unchanged with A : returns
1.00 blob
puts [db eval "SELECT DerefDict_SQL('A'),
typeof(DerefDict_SQL('A'))"] ;# B6 Unchanged with A : returns 1
real (!) <-
# Sequence C
set i [format %.2f [expr {1 + 0}]]
if {$i eq "0"} {}
puts [dict get $tclDict A] ;# C1 returns 1.00 Reference
puts [db eval {SELECT $i, typeof($i)}] ;# C2 Changed with B : returns
1.00 text
puts [db eval "SELECT :i, typeof(:i)"] ;# C3 Changed with B :
returns 1.00 text <-
puts [db eval "SELECT DerefDict_SQL('A'),
typeof(DerefDict_SQL('A'))"] ;# C4 Changed with B : returns 1.0 real
puts [db eval "SELECT @i, typeof(@i)"] ;# C5 Unchanged with B : returns
1.00 blob
puts [db eval "SELECT DerefDict_SQL('A'),
typeof(DerefDict_SQL('A'))"] ;# C6 Changed with B : returns 1.0
real <-
Thank you in advance.
Jean-Baptiste
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
