Quantcast

tclsqlite3 db function exports not visible on other connections. Why not?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

tclsqlite3 db function exports not visible on other connections. Why not?

petern
Taking DRH's remarks about learning tclsqlite for the efficient coding to
heart, I discovered a big problem.

Here is the simplest example from the docs and DRH presentation:

TCLSH
% db function myhex {format 0x%X};
% db eval {select myhex(10);} x {parray x};
x(*)         = myhex(10)
x(myhex(10)) = 0xA

Now, on the same database with simultaneous connection eg: shell, odbc, etc:

sqlite> select myhex(10);
Run Time: real 0.000 user 0.000000 sys 0.000000
Error: no such function: myhex

-----------------------------------------------------------------------------
Did I missing something in the docs?
Is there a trick/pragma to make this work?

Tclsqlite is extremely efficiently for extending sqlite but this facility
is generally useless if the whole application must be ported to (or at
least all db queries funneled through) TCLSH to use those easy to build
extensions.  What if the outer application can't be ported to TCL?

Is there another way, like preloading TCL code on the ODBC connection?
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tclsqlite3 db function exports not visible on other connections. Why not?

R Smith

On 2017/03/19 11:05 AM, petern wrote:

> Taking DRH's remarks about learning tclsqlite for the efficient coding to
> heart, I discovered a big problem.
>
> Here is the simplest example from the docs and DRH presentation:
>
> TCLSH
> % db function myhex {format 0x%X};
> % db eval {select myhex(10);} x {parray x};
> x(*)         = myhex(10)
> x(myhex(10)) = 0xA
>
> Now, on the same database with simultaneous connection eg: shell, odbc, etc:
>
> sqlite> select myhex(10);
> Run Time: real 0.000 user 0.000000 sys 0.000000
> Error: no such function: myhex
>
> -----------------------------------------------------------------------------
> Did I missing something in the docs?
> Is there a trick/pragma to make this work?
>
> Tclsqlite is extremely efficiently for extending sqlite but this facility
> is generally useless if the whole application must be ported to (or at
> least all db queries funneled through) TCLSH to use those easy to build
> extensions.  What if the outer application can't be ported to TCL?

Adding a custom function (Whether done in your code using the API or
using TCL or whatever) makes that function belong to the connection, a
function cannot belong to the database or persist outside of the
creating connection. tclsqlite is a great way to code for examples or
reproducible bugs or even full DB maintenance scripts - but you can't
use it together with your normal program code from a different
connection. I'm not sure if there exist any way (or hack) to achieve
this, maybe someone else knows, but what you tried won't work.

This is not a tclsqlite problem, if you open a connection from one of
your programs, add to it a custom function, and then open another
connection to the same DB from one of your other programs, the custom
function will of course NOT exist for the second connection - it's
strictly a per-connection thing, and the second connection must register
its own custom function.

There exist some add-ons for sqlite which introduce ways of creating
custom functions INSIDE the SQL via a query. Not sure if this will solve
your problem, if so ask again (or google) for links to them.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tclsqlite3 db function exports not visible on other connections. Why not?

Daniel Kamil Kozar
You can use sqlite3_auto_extension for this.

On 19 March 2017 at 11:35, R Smith <[hidden email]> wrote:

>
> On 2017/03/19 11:05 AM, petern wrote:
>>
>> Taking DRH's remarks about learning tclsqlite for the efficient coding to
>> heart, I discovered a big problem.
>>
>> Here is the simplest example from the docs and DRH presentation:
>>
>> TCLSH
>> % db function myhex {format 0x%X};
>> % db eval {select myhex(10);} x {parray x};
>> x(*)         = myhex(10)
>> x(myhex(10)) = 0xA
>>
>> Now, on the same database with simultaneous connection eg: shell, odbc,
>> etc:
>>
>> sqlite> select myhex(10);
>> Run Time: real 0.000 user 0.000000 sys 0.000000
>> Error: no such function: myhex
>>
>>
>> -----------------------------------------------------------------------------
>> Did I missing something in the docs?
>> Is there a trick/pragma to make this work?
>>
>> Tclsqlite is extremely efficiently for extending sqlite but this facility
>> is generally useless if the whole application must be ported to (or at
>> least all db queries funneled through) TCLSH to use those easy to build
>> extensions.  What if the outer application can't be ported to TCL?
>
>
> Adding a custom function (Whether done in your code using the API or using
> TCL or whatever) makes that function belong to the connection, a function
> cannot belong to the database or persist outside of the creating connection.
> tclsqlite is a great way to code for examples or reproducible bugs or even
> full DB maintenance scripts - but you can't use it together with your normal
> program code from a different connection. I'm not sure if there exist any
> way (or hack) to achieve this, maybe someone else knows, but what you tried
> won't work.
>
> This is not a tclsqlite problem, if you open a connection from one of your
> programs, add to it a custom function, and then open another connection to
> the same DB from one of your other programs, the custom function will of
> course NOT exist for the second connection - it's strictly a per-connection
> thing, and the second connection must register its own custom function.
>
> There exist some add-ons for sqlite which introduce ways of creating custom
> functions INSIDE the SQL via a query. Not sure if this will solve your
> problem, if so ask again (or google) for links to them.
>
>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tclsqlite3 db function exports not visible on other connections. Why not?

petern
Yes.  I am aware of https://www.sqlite.org/loadext.html

And that's a good point.  However, one might be under the impression that
SQLite is a TCL extension from DRH's presentation here:

http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2009/proceedings/sqlitetcl/tcl2009-sqlite.pdf

In fact, according to the title of that presentation, SQLite is the most
popular TCL extension in the world!

Furthermore, if the TCL byte code engine is already linked to the SQLite
binary, one would think user defined TCL byte code could be executed
directly instead of having to statically link the TCL byte code engine
again and again for each extension binary.

Here are some questions that need answers.

1. If it does, how does SQLite build the binary version of TCL code of its
implementation?

2. What is the recommended way of building a SQLite loadext compatible
library.so file from .tcl files and current tclsqlite3.c source file?



On Sun, Mar 19, 2017 at 4:44 AM, Daniel Kamil Kozar <[hidden email]>
wrote:

> You can use sqlite3_auto_extension for this.
>
> On 19 March 2017 at 11:35, R Smith <[hidden email]> wrote:
> >
> > On 2017/03/19 11:05 AM, petern wrote:
> >>
> >> Taking DRH's remarks about learning tclsqlite for the efficient coding
> to
> >> heart, I discovered a big problem.
> >>
> >> Here is the simplest example from the docs and DRH presentation:
> >>
> >> TCLSH
> >> % db function myhex {format 0x%X};
> >> % db eval {select myhex(10);} x {parray x};
> >> x(*)         = myhex(10)
> >> x(myhex(10)) = 0xA
> >>
> >> Now, on the same database with simultaneous connection eg: shell, odbc,
> >> etc:
> >>
> >> sqlite> select myhex(10);
> >> Run Time: real 0.000 user 0.000000 sys 0.000000
> >> Error: no such function: myhex
> >>
> >>
> >> ------------------------------------------------------------
> -----------------
> >> Did I missing something in the docs?
> >> Is there a trick/pragma to make this work?
> >>
> >> Tclsqlite is extremely efficiently for extending sqlite but this
> facility
> >> is generally useless if the whole application must be ported to (or at
> >> least all db queries funneled through) TCLSH to use those easy to build
> >> extensions.  What if the outer application can't be ported to TCL?
> >
> >
> > Adding a custom function (Whether done in your code using the API or
> using
> > TCL or whatever) makes that function belong to the connection, a function
> > cannot belong to the database or persist outside of the creating
> connection.
> > tclsqlite is a great way to code for examples or reproducible bugs or
> even
> > full DB maintenance scripts - but you can't use it together with your
> normal
> > program code from a different connection. I'm not sure if there exist any
> > way (or hack) to achieve this, maybe someone else knows, but what you
> tried
> > won't work.
> >
> > This is not a tclsqlite problem, if you open a connection from one of
> your
> > programs, add to it a custom function, and then open another connection
> to
> > the same DB from one of your other programs, the custom function will of
> > course NOT exist for the second connection - it's strictly a
> per-connection
> > thing, and the second connection must register its own custom function.
> >
> > There exist some add-ons for sqlite which introduce ways of creating
> custom
> > functions INSIDE the SQL via a query. Not sure if this will solve your
> > problem, if so ask again (or google) for links to them.
> >
> >
> >
> > _______________________________________________
> > sqlite-users mailing list
> > [hidden email]
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tclsqlite3 db function exports not visible on other connections. Why not?

Richard Hipp-3
On 3/19/17, petern <[hidden email]> wrote:
>
> In fact, according to the title of that presentation, SQLite is the most
> popular TCL extension in the world!
>
> Furthermore, if the TCL byte code engine is already linked to the SQLite
> binary, one would think user defined TCL byte code could be executed
> directly instead of having to statically link the TCL byte code engine
> again and again for each extension binary.

Being a TCL extension does not imply that the TCL byte code engine is
already linked in.

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tclsqlite3 db function exports not visible on other connections. Why not?

petern
You wouldn't happen to have a TCL script you can share which approximates
the SQLite interactive shell multiline input and .exit command to return to
tclsh?  Dot exit would be the only mandatory dot command needed.

On Sun, Mar 19, 2017 at 12:28 PM, Richard Hipp <[hidden email]> wrote:

> On 3/19/17, petern <[hidden email]> wrote:
> >
> > In fact, according to the title of that presentation, SQLite is the most
> > popular TCL extension in the world!
> >
> > Furthermore, if the TCL byte code engine is already linked to the SQLite
> > binary, one would think user defined TCL byte code could be executed
> > directly instead of having to statically link the TCL byte code engine
> > again and again for each extension binary.
>
> Being a TCL extension does not imply that the TCL byte code engine is
> already linked in.
>
> --
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Loading...