VA Smalltalk and open source databases


VA Smalltalk has its traditional background in large corporations where most of the data is stored in the 800 pound gorillas DB2 and Oracle. The support for these databases is very reliable and stable, and Instantiations keeps their support code up to date with the supported products.

But open source has reached the enterprise in many areas, including databases. The web designers brought in MySQL with their PHP sites and Postgres is not particularly unsuited for many things that typically were driven by DB2 in the past.

So the time has come to support these databases as well in VA Smalltalk. Of course you can always use an ODBC driver and get VA Smalltalk to talk to these DBs, but ODBC hast ist issues.

Marten has put quite some work into PostgreSQL and SQLite support for VA Smalltalk. In his latest Blog post he gives a short introduction to how far he got, what problems he found and where he could need a little help as well as a short introduction on installing and using it.

You can always download his stuff from VastGoodies.com.

I think we should have stable support for at least PostgreSQL, MySQL and SQLite in VA Smalltalk in order to give newbies a chance to get to speed with VA Smalltalk very quickly, for example if they want to port their Rails application or a PHP based web site over to Seaside. SQLite is especially interesting for (small) businesses who want to ship packaged end-user applications (home banking, shopping list management, accounting, media management etc.). Not all and everything today is written against a NoSQL database…

An easy migration path is especially important for users who came to Smalltalk via Squeak or Pharo, but need the ability to produce GUIs with native widgets. They should not be forced to switch databases as well, just because they want to use VA Smalltalk.

So Marten’s work is really essential here, and I hope we can improve on his foundation.

4 thoughts on “VA Smalltalk and open source databases

  1. Hi. Very interesting post. Instead of having to port or create drivers for PostgreSQL, MySQL, Sqlite, etc, why don’y you prefer SqueakDBX? It is working in Squeak, Pharo, and another person port it to Dolphin. So it should be easy. The only complicated part is FFI that I don’t know how is it in VA.

    However, SqueakDBX wrappes OpenDBX, this means it supports Firebird, Interbase, MS SQL Server, MySQL, Oracle, PostgreSQL, SQLite, SQLite 3 and Sybase ASE.

    In case you are interested: http://www.squeakdbx.org

    Cheers

    1. Mariano,

      thanks for your comment. SqueakDBX sounds very interesting: I’m following its progress closely since your ESUG’09 talk and use it when working in Pharo. The problem with your suggestion is that Instantiations has to be very careful not to break any code of their customers. There are quite a few applications out there in the wild that would cost a lot of money if they stand still for a day or two. On the other hand, only using a SqueakDBX port for the open source databases I’m talking about would increase the effort of making GLORP (or, more important, persistence Frameworks that are used but not maintained by anybody any more, like TOPLink or Micado or POLAR) and stuff working on top of both SqueakDBX and teh existing DB interface stuff. So what would be needed is a bridge between the existing DB stuff in VAST and the SqueakDBX stuff, which I am sure is feasible but increases complexity. But still the idea is inspiring…………😉

      1. Hi Joachim. Sorry, I misundertood one part of the post. I understood VA was trying to port new database drivers for MySQL, PostgreSQL and Sqlite3 to VA. That’s why I was “recommending” maybe port only one library like SqueakDBX🙂
        But then I understood what you said and doesn’t make sense at all.

        So…I am curious how database drivers work in VA. The DB2 and Oracle driver, how do they communicate to the database? they call the client (C) library with some kind of FFI?

        In addition, are they synchronous or asynchronous? I mean….when you send a query (or any other call to a C function), is the VM locked until the function asnwers?

        Now…each of the VA database driver (Oracle, DB2, etc) have a common API? So…you modified Glorp so that the VA DatabasAccessor talks to that API ? is this similar to the EXDI of VisualWorks?

        Sorry for going so offtopic, it is just very interesting for me😉
        Otherwise, we can talk in ESUG personally…

        Cheers

        Mariano

Comments are closed.