links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
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.