VASmalltalk – Some comments about the SQLiteWrapper

I was asked to write some words about the usage of the MSKSQLiteWrapper.

Well, actually I hoped, that most of the stuff can be read from the tests delivered with application “MSKSQLiteWrapperTests”, but additional documentation may not be that bad 🙂

Installation

Before starting with that library you should download the latest available library from www.sqlite.org. The downloaded library is about 500 KByte large and should be copied into the “bin”-directory of your VASmalltalk installation or running VASmalltalk application. That’s all !

GLORP, ABT and all other stuff …

With 8.02 an initial (old) version of GLORP is delivered with VASmalltalk. Therefore the whole idea about O/R mapping gets refreshed under our platform again. The VA-port of GLORP was written (back in those days at CampSmalltalk in Essen) against the database-interface of VASmalltalk (somewhere around VASmalltalk 5.5).

Therefore a database interface must be compatible with the VASmalltalk-database-interface to be useable with GLORP and additional code must be added/exchanged within the VADatabaseAccessor class. To my surprise some code for the MSKLSQLite wrapper has already been added to this class, but commented out.

Therefore out of the box the code will not work together with GLORP.

In addition to this the code in “GlorpDatabase” is not very extension-friendly (and packager friendly). In my opinion, references to DB2, Oracle, ODBC (on our platform) should be extracted to other applications and all those “Smalltalk at: Symbol” code should be rewritten …. what I am missing here is an information from Instantiations, how work (users might do) will be ensured not to get lost when the framework is updated to newer releases. Glorp is a typical example how ugly a Smalltalk code gets, when porting issues are more important – but beside this Glorp is a brilliant sotware, without any question: just don’t get me wrong here. But the code does not feel like VASmalltalk code.

An idea for Glorp under VA: move the VADatabaseAccessor class to GlorpVAPort to get more freedom to make VA programming.

Ok, I tried to write the VA-database layer (which is more or less undocumented and pretty boring code) for SQLite (MSKSQLiteWrapperApp), but according to users (Hello Igor !) there are some errors in it and I did not have time to fix these errors – simply because of the fact, that I did not use this wrapper code by myself. I wrote it, did some very simple applications and that was it. Users are invited to pick up this code, rewrite or write complete new code …. :-)))

Because of this the AbtLayer for the PostgreSQL wrapper is still missing ……..

Ok – enough with all those background information about the MSKSQLiteWrapper.

This entry was posted in Smalltalk and tagged , , . Bookmark the permalink.

6 Responses to VASmalltalk – Some comments about the SQLiteWrapper

  1. Hi. Your post is almost the same we suffered in Squeak/Pharo with Glorp. In our case, SqueakDatabaseAccessor was completly hardcoded to the PostgreSQL native driver (PGConnection and friends).
    We completly refactored that and now SqueakDatabaseAccessor talks directly to an abstract class DatabaseDriver. We defined an API there, and you can have multiple subclasses (multiple drivers). We created one of the native PostgreSQL driver (with the stuff we removed from SqueakDatabaseAccessor) and created a driver for SqueakDBX (which supports almost all databases). This way we can use Glorp with almost all databases.

    Just in case you are curious you can read more or less what we did here:
    http://www.squeakdbx.org/GLORP integration

  2. Pingback: VA Smalltalk and open source databases | Joachims Small World

  3. Alan Knight says:

    I agree that that’s not very extensible. The VWDatabaseAccessor was changed to have connectionClassForLogin: delegate the choice of connection class to the database platform, which is more extensible. That just wasn’t carried forward to the other accessors.

    The reason for the rather nasty Smalltalk at: statements (which really should be Dialect>>smalltalkAt:) was to keep the code base as much as possible in one place, so that things like refactorings and looking for senders wouldn’t miss code because it was off in platform-specific or database-specific packages. So the things that are in the GlorpPort packages are only those things which absolutely could not be written in a portable way regardless of which meta-tricks we used. That mostly means class extensions of classes not uniformly present or not named the same (e.g. for blocks) or other really platform-specific stuff.

    Also, I don’t know that there’s a reason that things that didn’t work through the Abt database layer have to have one written in order to work through Glorp. I did the original that way because that’s how it seemed like VA wanted to access databases. But it would be quite possible to have a VADatabaseAccessor subclass, or some parallel classes that would access some databases through more specific APIs. I don’t know that we’d want to write and maintain many different things written to different APIs, but the database accessor class is not doing all that much.

  4. May I ask if you have written down something about the VA Abt Database layer?

    • schrievkrom says:

      No, the MSKSQLiteAbtLayer application code was written by try & error coding to see, what classes or methods are called.

      For SQLite I’m writing a special MSK accessor class to get the work done – as Alan mentioned, this is not that difficult – lots of functionality is already provided by the MSQLSQLite wrapper classes, though some tests are commented out for VA and some stuff (e.g mapping clob columns produce wrong SQL code, serial columns do not work at all etc …) are not working at all.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s