UDBCSQLite and the location of the sqlite3 binary
Hi, From time to time, we use UDBCSQLite for our workshops and interactive documentation examples and is a pretty good project for bridging the Smalltalk world and the relational database world. A common glitch is locating the binary of sqlite3 for 32 bits and putting it in a place that is available for the VM. I just make this small hack: === UDBCSQLite3Library>>#library Smalltalk os isMacOS ifTrue: [ ^ #sqlite3 ]. Smalltalk os isUnix ifTrue: [ ^ '/usr/lib32/libsqlite3.so']. ^'sqlite3' === and now is working pretty well on my machine. Of course, this only works on Arch 64 bits and its derivates and could change in other Gnu/Linux variants. So, I'm wondering for a better way to make the path to the sqlite binary not hard coded into UDBCSQLite3 and creating some #library: setter that lets the user to setup the sqlite3 location if the file on UDBCSQLite3Library>>#library is non-existent or wrong. I'm sending this to the list, because AFAIK there is no ticketing on STHub to discuss code issues. Cheers, Offray
In Unix you can create a symlink at the vm directory pointing at the location of the shared object. That's what I do. Regards! Esteban A. Maringolo 2016-11-29 13:48 GMT-03:00 Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com>:
Hi,
From time to time, we use UDBCSQLite for our workshops and interactive documentation examples and is a pretty good project for bridging the Smalltalk world and the relational database world.
A common glitch is locating the binary of sqlite3 for 32 bits and putting it in a place that is available for the VM. I just make this small hack:
===
UDBCSQLite3Library>>#library
Smalltalk os isMacOS ifTrue: [ ^ #sqlite3 ]. Smalltalk os isUnix ifTrue: [ ^ '/usr/lib32/libsqlite3.so']. ^'sqlite3'
===
and now is working pretty well on my machine. Of course, this only works on Arch 64 bits and its derivates and could change in other Gnu/Linux variants. So, I'm wondering for a better way to make the path to the sqlite binary not hard coded into UDBCSQLite3 and creating some #library: setter that lets the user to setup the sqlite3 location if the file on UDBCSQLite3Library>>#library is non-existent or wrong.
I'm sending this to the list, because AFAIK there is no ticketing on STHub to discuss code issues.
Cheers,
Offray
Hi, On 29/11/16 13:20, Esteban A. Maringolo wrote:
In Unix you can create a symlink at the vm directory pointing at the location of the shared object.
That's what I do.
Regards!
Esteban A. Maringolo
Yes, I do the same, but that's precisely what I want to avoid. Having a setter for the sqlite binary makes it friendlier for new comers, by having the setup done in the image side, instead of the OS side, so you don't need to locate your VM (I don't know where it is in the case of Pharo Launcher) and even making it available if you have several VM and images without symlinking each time. Cheers, Offray
On Tue, Nov 29, 2016 at 11:48:42AM -0500, Offray Vladimir Luna Cárdenas wrote:
So, I'm wondering for a better way to make the path to the sqlite binary not hard coded into UDBCSQLite3 and creating some #library: setter that lets the user to setup the sqlite3 location if the file on UDBCSQLite3Library>>#library is non-existent or wrong.
Looks like this calls for a class variable to hold the library location that can be (re)set by the user / application programmer? In NBSQLite3 I have integrated SQLcipher which provides transparent full database encryption for SQLite. I keep libsqlcipher.so separate from libsqlite.so. To switch between SQLite and SQLcipher for the unit tests I remember using a class variable, in what may be called a 'doubleton' pattern. :-) The SQLcipher bits aren't in UDBCSQLite3 yet. I'm also working on using Ansible to deploy VM and images programmatically. Using this mechanism I deploy both libsqlite.so and libsqlcipher.so into the VM directory, so the situation where Pharo cannot find the shared library does not arise. Pierce
participants (3)
-
Esteban A. Maringolo -
Offray Vladimir Luna Cárdenas -
Pierce Ng