Storing tcl\tk scripts in database tables

[sled...@gmail.com]

Has anyone had the experience of storing a tcl script as a row in a sql managed database.

A user cannot use VPN to access a shared server. However, they do have access to a MySQL db stored as an Amazon Web Server. As a consequence, the thought has obviously occurred to place the 20+ tcl scripts in a row and 'source' them from there.


In order to head off spending time learning what I don't even know that I don't know, it would be useful to be aware of any gotcha's.

Currently, thinking of a two column table. Name and Body. Body contains the script as 'sourced' from a *.tcl file. The Body data type is Medium Text.

Am open to all suggestions (and\or constructive criticisms).

Is this possible or have I spent too much time smoking my bedsheets.

[David Rysdam]

Yes, this is possible. Obviously there are potential security issues,
but I've basically ignored those for my situation. The technical issue
is that you need to safely encode the Tcl so it doesn't confuse the SQL.
That means quotes and newlines at a minimum. Also, because our DB is
dumped in a text format, we needed to encode some additional characters
that would confuse the backup system, like tabs.

There are a couple of stupid tricks you can do with this. For one thing,
the Tcl code can go delete itself from the db, vanishing without a
trace. For another, you can overwrite existing code. That is, you can
have a proc or class defined in your "on disk" code that is overridden
by the "in the DB" code.

[Gerald Lester]

It has been done a number of time, including at least two commercial
products.

I'd strongly recommend the following columns:
ProcedureName
ProcedureArgs
ProcedureBody
LastChangeDate

This will allow you to, in the future, cache the results locally (say in
a Sqlite DB) and only ask for updates since your last refresh (cuts down
the network traffic).

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

[Matthew Hiles]

You can side step encoding issues by storing the proc body base64 encoded. Makes transparency and introspection a bit more tedious, but I've implemented RPC over regular sockets this way with good success.

[sled...@gmail.com]

On Tuesday, July 18, 2017 at 2:26:09 PM UTC-4, David Rysdam wrote:

Good stuff...knowing what I didn't know...thanks

[sled...@gmail.com]

Figured I would get your attentions {;-) thanks, again..

[sled...@gmail.com]

I was concerned about that...but was not aware of a solution. Thanks.

[Gerald Lester]

You can also use bind variables to read and write the scripts and let
the API take care of encoding.

[Torsten Berg]

I do something like this in my app. Every script is one item/record in an sqlite database, but not as plain text but blowfish encoded and then uuencoded afterwards to make it plain strings again. This makes the data larger by a fair amount but the scripts are typically small anyway so this is no problem.

Then I have columns in the database table for versioning and script/package name. This allows me to use a [package unknown] handler which, when something is not found inside my app bundle or on the host computer, then it automatically redirects to the database and loads the package/script from there.

Very handy, and very neat, since it make a good framework for in-app updates that just consist of updating a row in an SQLite table. My scripts do not live in a binary executable (like with tclkit or freewrap on Windows) but as portably readable/writable files (i.e the SQLite database) alongside the binary.

[sled...@gmail.com]

Hi,

Am going to need a little help with this explanation. What do you mean by 'bind' variables? Which API?

Rick.