Our experiences with different types of persistency mechanisms - flat files, relational databases, object-relational mapping and object-oriented databases - led to the wish of having an own small ODBMS as an alternative or supplement to typical RDBMS. This system shall not compete with larger commercial or open source databases. But it shall be a small and simple embeddable storrage system which seamlessly integrates into Smalltalk and enables us to rapidly develop small to mid-sized solutions. The result is the Tideland Smalltalk Object Store.
What are the design goals?
- Easy API
The interface to the developer as the user of the SOS shall be as easy as possible. Persistency shall be handled automaticly based on reachability of named root objects like described in the ODMG binding. Persistent classes don't need to be derived from a base class or implement special methods. Large objects, like long strings or images, shall be handled automaticly.
- Exchangeable Storrage Backends
While the API to the developer remains the same the backend for the physical storrage shall be exchangeable. So different need during development or production can be handled by choosing the adequate strategy. Beside own implementations relational databases shall be supported due to the trust into well-known technologie.
- High Performance
At least one strategy shall provide a high performance access.
- Garbage Collection
The ODBMS has to support automatic and manual garbage collection, dependig on the configuration. The strategies are responsible for the implementation of the garbage collection consistent with their persistency mechanism.
- Optimistic Concurrency Control
Especially for the usage in multi-user web applications pessimistic page locking is a no-go criteria. Instead the ODBMS has to support optimistic concurrency control on an object level.
- Schema Evolution Support
Times are changing, so do classes. Even if there is no tool support from the start the internal model used by the strategies has to support schema evolution.
- Simple Internal Model
The internal model shall allow a simple and natural external representation through the strategies so that external tools will be able to read it. This allows to build scripts for data migration into new successor applications.
What do we have reached today?
Most of our goals are allready realized, only strategies for relational databases are missing. But the technology is evaluated and will be integrated soon. Also schema evolution is missing, but right now the system handles the lazy adding of new and the deleting of obsolete instance variables automaticly. Only renamings or the adding with a given value for all instances are missing.