Re: [sqlite] 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  wrote:

> On 3/19/17, petern  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
> 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] tclsqlite3 db function exports not visible on other connections. Why not?

[Richard Hipp]

On 3/19/17, petern  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
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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 
wrote:

> You can use sqlite3_auto_extension for this.
>
> On 19 March 2017 at 11:35, R Smith  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.00 sys 0.00
> >> 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
> > 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
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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  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.00 sys 0.00
>> 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
> 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] 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.00 sys 0.00
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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] 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.00 sys 0.00
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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users