GlorpSQLite works on Pharo 7!
Take a fresh Pharo 7 alpha image; as of yesterday's download that is 5f13ae8. Launch it and run the following snippet in a Playground:
Run the Glorp tests in TestRunner. The result should be green, with all 891 tests passed and 12 tests skipped. The database file is sodbxtestu.db in your image directory. Tested on 32- and 64-bit Ubuntu 18.04.
I've updated ConfigurationOfGlorp for Pharo 6 and added catalog methods to ConfigurationOfGlorpSQLite.
Take a fresh Pharo 60365 image, the latest as of yesterday's download. Launch it, open the Catalog Browser, and install GlorpSQLite from there.
Run the Glorp tests in TestRunner. The result should be green, with all 889 tests passed and 12 tests skipped. The database file is sodbxtestu.db in your image directory.
(On Pharo 5, Glorp runs and passes total of 953 tests. Something to look into.)
I've created ConfigurationOfGlorpSQLite on STH.
Take a fresh Pharo 5 image. Make a script like the following and run it on the image:
When done, fire up the image again, and run the Glorp tests in TestRunner. The result should be green, with all 953 tests passed and 12 tests skipped. The database file is sodbxtestu.db in your image directory.
I'm pleased to announce the release of Glorp-SQLite3 for Pharo 5.
Developed and tested on Linux. Known working on Windows 7. Your Pharo 5 VM needs to be able to find libsqlite3.so or the Windows equivalent.
Take a fresh Pharo 5 image. Run the following:
Run the Glorp tests in TestRunner. All tests should pass, with 12 tests skipped. The database file is sodbxtestu.db in your image directory.
Using the Pharo v40592 image with which I had verified NBSQLite3 for Glorp, in this blog post I go through doing the same with the PostgresV2 pure-Smalltalk database driver.
Outside of Smalltalk, create the database 'sodbxtest', user 'sodbxtest' with password 'sodbxtest':
In Smalltalk, firstly, install PostgresV2:
Open Test Runner and runs the PostgresV2 tests. On my Linux Mint machine, using a vanilla PostgreSQL 9.3 installation, 23 of 24 tests passed, and TestPGConnection>>#testNotify2 erred.
Now that we know the PostgresV2 driver can talk to our database, using the Monticello browser, open the PostgresV2 repository and load the package GlorpDriverPostgreSQL. Here I had to edit NativePostgresDriver>>connectionArgsFromCurrentLogin: to comment out the second last line:
This is because GlorpDatabaseLoginResource class>defaultPostgreSQLLocalLogin does not specify encodingStrategy, meaning it is nil and will respond to #asSymbol with DNU.
Next, in a playground, execute the following:
Open Test Runner and run the Glorp tests.
Tested on Linux Mint 17.
I've integrated NBSQLite3 into Glorp on the current Pharo 4.0 v40592 beta image.
Firstly, install NBSQLite3 (TorstenBergmann.7) and then Glorp (TorstenBergmann.42) from the config browser.
Then, using the Monticello browser, open the NBSQLite3 repository and load the packages NBSQLite3-Glorp and NBSQLite3-Test-Glorp. Next, open the Glorp repository and load the packages Glorp-PierceNg.97.mcz and GlorpTests-PierceNg.44.mcz.
In a workspace/playground, execute the following:
Open Test Runner and run the Glorp tests.
Tested on Linux Mint 17 and OSX Mavericks. 2 fewer tests passed on Linux.
Curiously, #testLargeBlob, #testLargeClob and #testLargeText passed on the Pharo 3 image that I wrote this code on.
The database file created by the tests is sodbxtest.db.
Made really good progress with NBSQLite3 for Glorp.
On the failed tests:
#testReadTimestamp - SQLite3 does not support date/time/timestamp types natively. More investigation needed. #testDateCast - The test itself says, "This test will fail on SQLite which has no DB Date type; see test comment." #testDeleteAndReinsertTwiceWhenRemovingFromAnExclusiveCollection - This test is expected to result in a primary key conflict. Without studying the code, my conjecture is that the test's failing has to do with SQLite's primary key handling. #testInt8 - Integer overflow on 32-bit SQLite, I think. #testPreparedStatementsAreReused - PostgresV2 doesn't support prepared statements. NBSQLite3 does. Mayhaps this is why? More investigation needed. #testUpdatingComment - Test passes on OSX Mavericks but fails on Linux Mint 17. No idea why. #testUpdatingOtherThing - Test passes on OSX Mavericks but fails on Linux Mint 17. No idea why.
The entire GlorpOptimisticLockingTest and GlorpTimestampTest suites are skipped, because some of the tests fail, and foobars the Pharo-SQLite interface, causing many subsequent tests to fail, requiring restart of the Pharo image. Still need to look into these.
Making good progress with NBSQLite3 for Glorp.
Sven van Caekenberghe has written a very nice tutorial implementing a Reddit clone in Pharo using Seaside, Glorp and PostgreSQL. Sven also makes available a prebuilt image containing the application.
Seeing that the image contains Glorp working with the PostgresV2 driver, I set about integrating NBSQLite3 with Glorp. After about an afternoon's work, I now have Reddit.st working with Glorp+NBSQLite3.
There is still much to be done to get Glorp fully working with NBSQLite3: Some tests apparently expect Glorp proxies, but are getting OrderedCollections, and one particular test rendered my Linux X session non-responsive to mouse and keyboard, except for screen brightness key chords!
I'm reading the book Seven Databases in Seven Weeks by Eric Redmond and Jim Wilson. The databases covered are PostgreSQL, Riak, HBase, MongoDB, CouchDB, Neo4J and Redis.
There are several Pharo/Squeak libraries for PostgreSQL:
HBase runs on JVM. It supports a RESTful HTTP API, Thrift, and a Java API. The first is probably the easiest way to write a Smalltalk interface.
Neo4J is a graph database. It is provides a RESTful API. I've not played with Neo4J, but I'd imagine the Smalltalk environment, and by extension any Smalltalk object persistence mechanism, make up a graph database. Probably speaking from ignorance here, but I'm not sure what interest a Smalltalk programmer will have in a graph database written in Java. :-)
Finally, there is Redis Client by Mike Hale and others.
I haven't finished the book, but so far I haven't seen any discussion on authentication or security of these HTTP-speaking NoSQL databases. If the database is lacking authentication or SSL, and if your threat model covers that, probably the easiest is to put these behind a proxy. And, for database and other such connectivity from the Smalltalk client, I suggest SpsSplitPasswordStore.
GOODS "is an object oriented fully distrbuted database management system using an active client model." It is also described as a "language-neutral object database" with client interfaces for C++, Java and Perl. GOODS is written by Konstantin Knizhnik.
Avi Bryant developed a Squeak client for GOODS that allows transparent storage of Smalltalk objects. The client is now maintained for Pharo, Squeak and VisualWorks by David Shaffer and is hosted on SqueakSource3.
GOODS works over TCP and Unix domain sockets. However, the GOODS documentation doesn't actually describe how to configure for the latter. There is, however, a hint in the main configuration file "goodsrv.cfg":
In addition to the main configuration file, there is database-specific configuration file, which I've named "test.cfg", that looks like this:
This matches the configuration format:
Meaning, for test.cfg, I'm specifying one storage server, and it listens on TCP port 60060 on localhost.
But what about the Unix domain socket path? To find out, I set the server.remote.connections parameter to 0 and try it out:
What happened? Looking around, it is found that GOODS has created a Unix domain socket at "/tmp/localhost:60060". Yes, ":60060" is part of the socket's path name. Cute. Trying to use a more descriptive name like "goodsock" or whatever fails with "bad address". Hitting the GOODS source, unisock.cxx shows that that unix_socket_dir is hardcoded to "/tmp/", and that the file name format has to be "string:number".
Oh well. I've abstracted the procedure to obtain a Unix domain socket address from a path string from my previous post as follows:
However, asking for a Unix domain socket address for "/tmp/localhost:60060" causes primGetAddressInfoHost:blah:blah: to fail. Bummer.
Okay, it is easier to modify GOODS since I've been browsing its source, then to get well-acquainted with SocketPlugin. So, at line 107 of unisock.cxx, make this change:
The commented out line is the original. "hostname" is "address" minus the colon and port number that comes after it.
Rebuild GOODS, change the path in test.cfg to say "goodserver:60060", restart, and we see that the Unix domain socket is now called "/tmp/goodserver" and "NetNameResolver addressForSocketPath: '/tmp/goodserver'" duly returns a SocketAddress instance.
Next, load the Squeak/Pharo GOODS client from SS3. Subclass KKSqueakTCPSocketTransport as KKPharoIPCSocketTransport, with the single method:
Some other corresponding modifications are needed, such as in KKDatabase and KKConnection. Finally, in workspace, run this:
And it works!
Running "self logout" in the KKDatabase instance explorer from above results in additional output from GOODS: