Home/ Questions/Q 6885261
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T05:36:45+00:00

I’ve been spending some time lately getting acquainted with Smalltalk and Seaside. I’m coming

  • 0

I’ve been spending some time lately getting acquainted with Smalltalk and Seaside. I’m coming from the Java EE world and as you can imagine it’s been challenging getting my mind around some of the Smalltalk concepts. 🙂

At the moment I’m trying to grasp how data persistence is most typically implemented in the Smalltalk world. The assumption for me as a Java programmer is to use RDMS (ie. MySQL) and ORM (ie. Hibernate). I understand that is not the case for Smalltalk (using Hibernate at least). I’m not necessarily seeking the method that maps most closely to the way it is done in Java EE.

Is it most common to save data into the image, an object store or RDMS? Is it even typical for Smalltalk apps to use RDMS?

I understand there is no one-size-fits-all approach here and the right persistence strategy will depend on the needs of the application (how much data, concurrency, etc). What’s a good approach that can start simple but also scale?

I’ve watched a video of Avi Bryant discussing the strategy he used for persistence and scaling DabbleDB. From what I understand, the customer’s data was saved right into the image (one image per customer). That worked in his use case since customers didn’t have to share data. Is this a common approach?

Hope I didn’t make this TLDR. Many thanks to the insight you Smalltalk guys have provided in my previous questions. It’s appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Justin,

    don’t worry, Smalltalk is not so different form other languages in this area, it just adds the Image based persistence option.

    There are O/R mappers like Hibernate for Smalltalk, the GLORP and its Pharo port DBXtalk are surely the most popular ones these days. These should feel very comfortable for you if you know Hibernate.

    Then there are OODB solutions like GemStone or Magma DB or VOSS and many others that let you leave all the O/R-mapping problems behind. Most of these are pretty limited to storing Smalltalk objects, GemStone being an exception in providing bridges to Ruby and other languages.

    There also are tools to store Smalltalk objects in modern NoSQL databases like CouchDB, Cassandra, GOODS or others. The trick here is just the conversion of Smalltalk object values to JSON streams and a little HTTP-requesting.

    Finally there is the option of saving your complete Smalltalk image. I’d say you can do that in a production environment, but it’s not the standard or preferred way of dong it for many people. You do it a lot in development, because you can simply save an image and resume your work the next time exactly with all objects in place as you had them when you saved.

    So the base line is: All the storage options you know are available in Smalltalk as well, plus one extra.

    Joachim

    • 0