[Seaside] Options for persistence when using Seaside
stephan at stack.nl
Fri May 15 20:16:57 UTC 2009
Ok, here is a first draft. Please send me (or to the list)
- other possible solutions
- other scenario's
- other questions that are relevant to make a good decision
- sample code
- information on reference implementations
- 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
There are a lot of different technological solutions for this problem.
This document should help you decide what is the right solution for you.
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
- use an OODB
- use an ORM to a RDB
- store in the cloud
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
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.
Clustering/ automatic fail-over etc.
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
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 := ADPerson new.
person lastName: 'Jansen'.
ADPerson persons add: person
Goods backend for SandstoneDB: http://www.squeaksource.com/SDGoodsStore
Magma mailing list: http://lists.squeakfoundation.org/pipermail/magma/
More information about the seaside