It turned out that @orr721 had been using Ren-C with ODBC for a couple of years (to process data from Microsoft Excel). I'd been on the fence about its relevance, because it seems a very "legacy" type of technology... I'm more interested in graph databases and non-SQL-oriented storage engines. Also, the bit of PORT!-related cruft as an interface seemed very poorly thought out (as I feel pretty much all of ports have been shown to be).
But since he'd been using it and filed a bug report--and I've been asking people to give me reproducible tests for things they care about to put on Travis--I figured I could patch it up. I did so in a way that pushed it along even further as a libRebol client; various commits I made showed flexing the muscles of the API and its approach.
But not wanting the work to atrophy again, I created a new rebol-odbc GitHub with its own .travis.yml file and issue database. I made it run a primordial but somewhat broad insert and select
%odbc-test.reb, which puts various datatypes into a table from Rebol values, and then checks to see that the same values can be gotten back out.
The test is now automated and running and succeeding on MySQL as well as succeeding under SQLite on unixodbc. Linux is the more complicated environment to get thing working on, as ODBC originates from Microsoft--so it's more turnkey there.
I Might Be Underestimating How Useful This Is
Rebol2's ODBC abilities were considered valuable enough that they were a paid feature. One implication of that is that few people ever had a chance to experience a single-download tool that can manipulate ODBC databases and translate fields to native types, while offering the language abilities of Rebol2. (So they sure haven't seen what such a tool with Ren-C can do!)
I went hunting for a vetted open-source alternative client that could do arbitrary SQL commands on DBC databases on your machine. There was pretty much no kind of "simple" option.
But I already had Python available on the machine:
shell> python --version Python 2.7.15+
So since there was a "pyodbc" I thought I'd install it. However to get it, I had to install the Python Package Manager. This is what
sudo apt install python-pip gave back:
The following additional packages will be installed: libexpat1-dev libjs-sphinxdoc libpython-all-dev libpython-dev libpython2-dev libpython2.7 libpython2.7-dev libpython2.7-minimal libpython2.7-stdlib python-all python-all-dev python-asn1crypto python-cffi-backend python-configparser python-crypto python-cryptography python-dev python-entrypoints python-enum34 python-idna python-ipaddress python-keyring python-keyrings.alt python-pip-whl python-pkg-resources python-secretstorage python-setuptools python-six python-wheel python-xdg python2-dev python2.7 python2.7-dev python2.7-minimal Suggested packages: python-crypto-doc python-cryptography-doc python-cryptography-vectors python-enum34-doc gnome-keyring gir1.2-gnomekeyring-1.0 python-fs python-gdata python-keyczar python-secretstorage-doc python-setuptools-doc python2.7-doc binfmt-support The following NEW packages will be installed: libexpat1-dev libjs-sphinxdoc libpython-all-dev libpython-dev libpython2-dev libpython2.7-dev python-all python-all-dev python-asn1crypto python-cffi-backend python-configparser python-crypto python-cryptography python-dev python-entrypoints python-enum34 python-idna python-ipaddress python-keyring python-keyrings.alt python-pip python-pip-whl python-pkg-resources python-secretstorage python-setuptools python-six python-wheel python-xdg python2-dev python2.7-dev The following packages will be upgraded: libpython2.7 libpython2.7-minimal libpython2.7-stdlib python2.7 python2.7-minimal 5 upgraded, 30 newly installed, 0 to remove and 191 not upgraded. Need to get 40.1 MB of archives. After this operation, 66.7 MB of additional disk space will be used.
So I need to download and decompress 40.1 MB of data, to take up 66.7 MB of disk (spread across who knows how many files), when I already had a python interpreter on the machine? And this won't even get me pyodbc!
All right, fine. After installing, I'd gone from 2.7.15+ to 2.7.16:
shell> python --version Python 2.7.16
Running pip install pyodbc wasn't egregiously big, but still seemed dauntingly complex:
Collecting pyodbc Downloading https://files.pythonhosted.org/packages/75/29/aa190749bac37ede0f11a68a75e7055254699c11572bd94213f1163dfd8f/pyodbc-4.0.27.tar.gz (242kB) 100% |████████████████████████████████| 245kB 1.9MB/s Building wheels for collected packages: pyodbc Running setup.py bdist_wheel for pyodbc ... done Stored in directory: /home/hostilefork/.cache/pip/wheels/87/b7/78/0740a2ed98bfe463525ad42d535370e34141c5d36b2d00dcaf Successfully built pyodbc Installing collected packages: pyodbc Successfully installed pyodbc-4.0.27
Putting aside the "what the heck is"
...wheels/87/b7/78/0740a2..., the package manager actually built the shared library. So the specification of the package is parallel to our "extensions"--presumably if you're on windows then
pip install pyodbc would be able to adapt its compiler settings and make a .DLL against Windows APIs as opposed to a
.so against POSIX. Unlike apt, it seems that pip does installation on a per-user basis by default.
-rwxrwxr-x 1 hostilefork hostilefork 832848 Oct 18 17:33 /home/hostilefork/.local/lib/python2.7/site-packages/pyodbc.so*
So over 800k of binaries just for the ODBC part. That doesn't make much sense, as most all the ODBC functionality is a shared library. What could all of that be?
Maybe There Is Opportunity Here
I don't know how big the cross-platform ODBC market is, and I've already mentioned my personal reluctance in getting involved in packaging binaries. But I did have a thought...
I've already suggested that the Trojan Horse of distributing the system might be to give people utilities built on Rebol that don't try and sell them the language, but try to sell them particular functionality (a dialect, etc.) built with the language.
What if every encapped application could sense its filename and then if it was
rebol, or some other list of special terms) it would automatically act as plain Rebol?
This means userbases could be identified to market a tool to. You build for the platforms of interest to them and encap the tool inside it.
I don't know what kind of ODBC-powered tool people might imagine, but it seems the world doesn't really even have a basic cross-platform string-based SQL query sorted out. If you imagine just a few nice features built on the usermode console and a dialect, I wonder... might there even be money in that?
My own attention should be on the web build--but if there were others who came with an interest in this, it wouldn't hurt. I don't know. As I say, I just sensed a vacuum and was struck at how there might be an opportunity here.