Introduction

This document contains some recommendations from the designers of DRAGOS on what we consider best practices or simply helpful bits and pieces that did not appear anywhere else yet.

Order and initialization of extensions

A single extension may require several steps of initialization. For example, you might have to wrap your graph pool and activate the Wrapper and GraphPoolChecker implementations supplied with the extension. When using multiple extensions, it is important to initialize them in the same order in each of these areas. To minimize the danger of mistakes and reduce the burden on developers and users, we introduced the VersionDescriptor interface, which we expect to be used by most extensions. But in case you need to manually initialize the different parts that make up an extension, you have to keep this in mind.

Since extensions are not restricted in the functionality they may implement, determining their interactions and dependencies and ordering them accordingly can be difficult.

For the extensions developed here at i3, the correct order would be (from innermost outwards):

  • dragos-ext-autocommit
  • dragos-ext-versions
  • dragos-ext-attreval

You can leave out any of the above extensions.

Explanation:

dragos-ext-versions must be below dragos-ext-attreval so it can intercept the setMetaAttribute calls used to set the formulae for the dynamic attributes. Otherwise, these would be outside of version control.

dragos-ext-autocommit must be below these two, since it can only intercept the basic operations defined in the Core GM, not the new operations defined in the extensions. If it was above the others, it would have to be "peeled away" by unwrapping before such a custom method is called, and the method might execute without a valid transaction context.