Options for persistence when using Seaside

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/



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> - use an ORM to a RDB
>   - SqueakDBX
- Magritte-RDB
- MySQL
>   - GLORP
there is also ROE

Keith
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi!

There is also at least two more interesting new options not mentioned:

        - CouchDB
        - TokyoTyrant

There is a Curl-plugin based Couch API on SS that I have played with a
bit. I have also written a so called "view server" in Squeak for CouchDB
which means you can write map/reduce-functions to execute "in the
server" in Squeak instead of in javascript. Mostly for fun - not really
super useful! :)

At my current customer I have written a C# API for CouchDB that we will
release under some BSD license any day now - I will probably take that
experience/design and translate it into improvements to the Couch API on
SS. I am unsure if the Curl plugin is better/faster than a Squeak-only
HTTP client approach.

CouchDB itself is a refreshing experience, vibrant very helpful
community, written in Erlang, HTTP API, JSON used as "object format",
interesting map/reduce-pattern etc etc. Built for "crazy scaling through
replication". Our first tests at my customer reveals great speed and
very nice flexibility.

TokyoTyrant is the networking server part used on top of Tokyo Cabinet -
a very fast key/value-store written in C. I implemented the TokyoTyrant
binary socket protocol recently and blogged about it:

http://goran.krampe.se/blog/Squeak/TokyoTyrant.rdoc

Awesome speed, very interesting functionality - especially the table db
part. I am using (or will be using) both of these from Squeak in
different projects.

regards, Göran

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside