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 |
Free forum by Nabble | Edit this page |