What is meant by transparent access?
Last updated at 10:17 pm UTC on 12 October 2008
Magma offers exceptional read and write transparency.
Read Transparency
Magma provides total read-transparency. Beyond the initial request for the #root object of the repository from a MagmaSession, your program is free to explore the persistent root object normally. Although the size of the persistent root may be many times the size of available RAM, Magma will page in requested portions and out portions no longer referenced by the program (Magma uses weak collections for its caching, so your program only consumes as much memory as the objects it references).
Write Transparency
Write-transparency is high as databases go in that Magma determines new and changed portions of the model automatically. The only requirement is that the application program define changes the model via atomic transactions. Transactions are a common semantic in databases for preserving integrity of changes. A number of commit-strategies allow Magma to be suitable for a variety of programs and users.
Benefits
This level of transparency allows existing objects which have never been designed to reside in a database to reside in Magma. For example, no Morph knows anything about Magma, but Morphs may be stored, shared and collaborated via Magma.
Object databases support complex domain relationships without any the mapping burden associated with relational mapping tools. There is no need for signaling changes, marking dirty, code-generation, attribute-column associating, or any of the other things that burden developers when using even modern relational mapping tools. As good as they are, they just cannot achieve the level of transparency of a true ODBMS.
Developers are free to use complex object models with impunity. Domain code remains pure, and independent of storage.
