[Seaside] Options for persistence when using Seaside

[Stephan Eggermont]

Ok, here is a first draft. Please send me (or to the list)
- comments
- other possible solutions
- other scenario's
- other questions that are relevant to make a good decision
- sample code
- information on reference implementations
- links
- answers to the questions in the doc.
I'll summarize and try to create a similar document to the pdf one.

Stephan at stack dot nl


Options for persistence when using Seaside

When building an application with Seaside, one often has a need to  
persist data.
There are a lot of different technological solutions for this problem.
This document should help you decide what is the right solution for you.

Overview

The number of different possible solutions is large:
- do nothing, simply save the image
- write binary files with objects
- write SIXX, smalltalk interchange xml
- use imagesegments
- use a prevayler-like solution
   - SandstoneDB
   - sPrevayler
- use an OODB
   - gemstone
   - goods
   - magma
- use an ORM to a RDB
   - SqueakDBX
   - GLORP
- store in the cloud

Availability

Seaside is available on a number of different platforms.
Not all persistence solutions are available on all platforms.
It is useful to make a breakdown into:
- operating system/version (Windows, Mac OS X, Linux, etc.)
- smalltalk platform (Squeak, Pharo, Gemstone, VW, VA, Dolphin, etc.)
- versions supported

Performance

Each persistence solution has  different performance characteristics.
How many objects can be handled on what hardware, how many
updates can be handled/second, how many simultaneous users
can be supported.

Special features

Clustering/ automatic fail-over etc.

Scenario's

In different situations, there are different storage needs

1 You are writing a small demonstration program to show your customers,
   and want to populate the system with some representative data.
   - Add a class instance variable to store the instances, and simply  
save the image.

2 You have a small system with a few hundred/thousand objects,
   and are not dependent on external systems.
   - A prevayler-like system like SandstoneDB might be a perfect fit.
     Each object save means a disk access,
     so scaling ends with disk speed.
    A few old versions of the data are kept around,
     so backing up or reverting is easy.
   - If you want a readable representation, SIXX might help.

3 You have a legacy (relational) database, with extensive reporting  
written for it.
   - Use an ORM

4 You have a complex and large object model that has to
   support changing the object model while developing.
   - the solution is an OODB
     - Gemstone is the large and proven commercial offering.
     It has a free version for smaller databases
     (4GB data, 1 core, 1G ram), and has proven
     scalability to 500 machines.
     - Magma is an open source OODB

Sample code

Keep data in the image
On the class side, add an instance variable:
ADPerson class instanceVariableNames: 'persons'
Add an accessor
persons ^persons ifNil: [persons := IdentitySet new]

Make it possible to empty the dataset

reset persons := nil

Create a new entity and add it to the dataset

|person|
person := ADPerson new.
person lastName: 'Jansen'.
ADPerson persons add: person
Links

Gemstone http://seaside.gemstone.com/
SandstoneDB http://onsmalltalk.com/
Goods: http://www.garret.ru/goods.html
Goods backend for SandstoneDB: http://www.squeaksource.com/SDGoodsStore
Magma mailing list: http://lists.squeakfoundation.org/pipermail/magma/