Extra! Gemstone Goes Seaside!
21 November, 2006
The lesson here is watch which key you press! Dale Henrichs from Gemstone accidentally posted his GemStone code to the Seaside Repository. It looks like we can expect Seaside to work with Gemstone coming soon.
In Dales own words: We’ll make an announcement to this list when all of the pieces are in place (including information about downloading non-commerce/trial versions). Our target date for having everything ready is Smalltalk Solutions 2007. If things continue to go smoothly, we are likely to be ready sooner.
Remember you heard it here first! Ok well you heard it first on the seaside list, but you heard it here second!
The Weekly Squeak 
21 November, 2006 at 22:23
Being only just a Smalltalk, Squeak and Seaside novice, can someone explain what Gemstone actually does and why this would be a good thing for Seaside? Will it only be non-commercial/trail?
21 November, 2006 at 22:47
[…] (Via The Weekly Squeak) Suite a une fausse manoeuvre sur la liste de diffusion Seaside, on a apprit qu’il va bientôt être possible d’utiliser Gemstone avec le framework web basé sur les continuations Seaside. Gemstone est une base de données objet multi-utilisateur, extrêmement performanten, basée sur des technologies Smalltalk. […]
22 November, 2006 at 01:00
@Geert,
Gemstone is an object database. Think of Oracle or SQLServer but for objects. Object databases have many advantages for object oriented languages because of the ease of persistence and traversals. The major arguments against using Object Databases are the same arguments against using Smalltalk. It is not proven, not scalable, not supportable, and needs expensive specialized programmers. Of course Gemstone is and has been used extensively, their scalability may not extend into the stratosphere like Oracle but in many cases where object databases really shine such extreme scalability is not necessary, it is supportable and really good programmers and DBA’s are hard to find in any language.
There are a few Gemstone competitors and one that is even written entirely in Java.
As for commercial availability, the free version is intended to let you try before you buy. They would not write the code if they didn’t plan to sell and support it. Seaside is not just for Squeak any more! (and hasn’t been for a while see the VW port!)
-Ron Teitelbaum
23 November, 2006 at 03:16
Thanks for that Ron. What would be the most used database for Seaside/Squeak nowadays?
23 November, 2006 at 04:08
@Geert,
That is a very good question. There are a lot of answers to that question depending on your situation. There are a number of squeak solutions that can help you.
There is a squeak OODB named Magma. You can use regular SQL dbms’ using an ODBC connection. There is a PostGreSQL v2 client that you can use. (PostGreSQL is an open source DBMS. I highly recommend it). You will need some of our cryptography code to get it working.
If you are not into SQL yourself and need mapping software look at GLORP. GLORP was written by the guys that did TOPLink and is really really cool. (Don’t SQL without it)
If you are doing very small things then you might just want to throw your own files.
Or you could wait for the new GemStone code.
So the answer is: It depends.
-Ron Teitelbaum
Squeak Cryptography Team Leader
Squeak News Team Member
23 November, 2006 at 05:48
What database does DabbleDB actually use?
24 November, 2006 at 03:12
From: http://jeffporten.com/2006/04/07/dabbledb-coolest-web-site-ive-seen-this-week/
Avi Bryant, April 10th, 2006 at 7:27 pm
Brian,
The first thing to point out is that we don’t use a traditional RDBMS as the backend – we’ve got a custom object database (though very relationally influenced in design) that manages this stuff.
However, in RDBMS terms, the simplest way to describe what the internals look like is that each field the user defines maps to a separate *table* in the backend, which has two columns (source, target), neither of which has to be unique. That make any sense?
15 December, 2006 at 03:41
The great thing about Gemstone (and other pure OODBMSes) is that it provides persistence without the need to translate objects into traditional RDMS structures. You don’t need to map your object and it’s variables to a table and columns. You can traverse your objects almost in the identical way you do for objects instanciated in your Smalltalk image. Collection classes are traversed pretty much as you would before using the DBMS.
What the OODBMS vendor does on the backend to make the data persistent and reinstate that data back into an object is up to them.
I recall one of the few changes that had to be made is opening the DB and defining commit points.
5 May, 2007 at 17:26
It is worth noting that with the port of Seaside to Gemstone, it is not necessary to define transaction boundaries in your Seaside application (i.e., beginTranscation/commitTransaction points). The transaction boundaries are built into the Seaside framework – in the Gemstone port, a beginTransaction is performed when the request comes in from the http server and a commitTransaction is performed right before the response is shipped out to the http server.
This means that while your Seaside application is responding to the request, you have an up-to-date ‘view’ of the object graph and any changes that you make to persistent objects will be committed to the data base, without _any_ special coding on your part.
When you scale your application and use more than one gem server, you will need to deal with concurrency issues. In most cases, this will involve using one of the Reduced Conflict classes that Gemstone provides as part of it’s class library.