Magma programming guidelines and best practices
Last updated at 9:01 pm UTC on 19 April 2011
Designing for an ODBMS
There are a number of design considerations when writing a Magma program. For more information:
Magma Commit Strategies
Optimizing Magma's Performance
About read strategies
Use MagmaCollections as a last resort
MagmaCollections solve a very-specific use-case, but many new users to Magma, particularly those that come from a RDBMS background, automatically gravitate toward creating a huge list of objects in a MagmaCollection. MagmaCollections are the slowest part of Magma; it is much better to use a rich object model and only use MagmaCollections when absolutely necessary.
Don't use a Dictionary for your root
Collections, by default, read to 1-level deep. Therefore, as your root gets more and more entries, it will take longer to send #root to your session.
It's also just not good object-oriented style; it is much better to employ a first-class grande-container for the root.
Multiple Sessions to one Repository in the same Image
Do not share objects between MagmaSession instances. Two or more separate MagmaSessions should never reference the same identical object intance, including proxies. Each session must always keep its own separate view of the persistent model, they should never be linked across sessions. The persistent objects are still identical within the repository, just not in the image across session views.
Custom indexes
Custom index types must inherit from MaIndexDefinition because all index definitions are part of the protocol between clients and server. This also means that the server must be started after the custom index was created and must be present in the servers image.
Since the server requires no other domain classes (though it won't hurt to have them), you may wish to define your custom index types in a separate package.
