UDBCSQLite and the location of the sqlite3 binary

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

UDBCSQLite and the location of the sqlite3 binary

Offray Vladimir Luna Cárdenas-2
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



Reply | Threaded
Open this post in threaded view
|

Re: UDBCSQLite and the location of the sqlite3 binary

Esteban A. Maringolo
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
<[hidden email]>:

> 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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: UDBCSQLite and the location of the sqlite3 binary

Offray Vladimir Luna Cárdenas-2
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




Reply | Threaded
Open this post in threaded view
|

Re: UDBCSQLite and the location of the sqlite3 binary

Pierce Ng-3
In reply to this post by Offray Vladimir Luna Cárdenas-2
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