Data persistence in Smalltalk / Seaside

Question

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.

Intermediary

Answer 1

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

Cavalierly

State of docs is a poor indicator for liveness in the smalltalk realm. Smalltalk has white-box reuse, not black box. There is activity on the mailing list forum.world.st/GLORP-f3496819.html – Unfeeling

Wojciech, Glorp is poorly documented and most Web sites that refer to it are outdated. That is not true for the code, however. It is maintained be developers of one of the major commercial Smalltalk vendors. So I understand your frustration about the documentation, but as Stephan notes, there is the Glorp mailing list where you can ask for help. There also are slides from a talk from the 2013 ESUG conference about Glorp that go very deep. But, yes, you are right: the documentation situation is very bad. – Predicament

Answer 2

I guess it basically depends on how big your DB is going to be and what kind of load will it be handling.

In my case, all apps I ever wrote use image persistance with disk serialization. Essentially, you just serialize your objects by using Fuel at request. In my case, I do so every time an important piece of data is dealt with, plus a regular process that serializes them every 24 hours. The image is also automatically saved every 24 hours.

The biggest application I wrote by using this approach is handling all the business processes of a small company of 10 workers plus around 50 freelancers who have been using it every day for a year and a half. The workload is pretty "big" taking in account the application deals with big files all the time, but the app has stayed stable and fast. Switching to a new server and updating the Pharo image was as easy as getting the project back from monticello and materializing the latest serialized "database".

In my opinion, ORM is an unnecessary pain, we're in the object world, and having to flatten our objects feels just wrong, especially when we have nice object-oriented solutions.

So, if your app handles fairly small amounts of data, I'd suggest either my simple approach or SandstoneDB. If your app deals with huge amounts of transactions and data, I'd go Gemstone.

Just my two cents.

Coadunate

Answer 3

Ramon Leon describes the situation, basic strategies, and their tradeoffs beautifully in his blog post.

I would start with his Simple Image Based Persistence framework, which I ported and use in Pharo 1.3. Mariano Martinez Peck recently adapted it to use Fuel (same link). It's very simple, does the job, and gives me much more confidence to play in my image, knowing that even if I permanently damage it, all my data is safe. I just copy the data folders to the new image folder, load my packages, and all my objects are alive in the new image.

Listen