GemStone code synchronisation
Automatic code synchronisation from GT to GemStone can be configured by setting the codeSync in the GtGemStoneSessionRegistry
.
Currently code synchronisation must be configured manually, typically in a user startup script.
A simple configuration is:
GtGemStoneSessionRegistry default codeSync: (GtGemStoneCodeSync new defaultClassStrategy: (GtGemStoneCodeSyncSubclassClassStrategy new superclass: #GemStoneObject asClass)) start.
GtGemStoneCodeSync
listens to the Epicea monitor (EpMonitor
) for code changes and filters by attributes of the changed class using the classStrategy, in this example any subclass of the hyperthetical GemStoneObject class. The default session strategy (GtGemStoneCodeSyncSessionStrategy
) forwards the changes to any session that has the codeSyncEnabled flag set in the session, which can be done through the session inspector.
An example that sets the session strategy explicitly:
GtGemStoneSessionRegistry default codeSync:
(GtGemStoneCodeSync new
sessionStrategy: GtGemStoneCodeSyncDefaultSessionStrategy new;
defaultClassStrategy: (GtGemStoneCodeSyncCategoriesStrategy new categories: { 'MyGemStone*' })) start.
will sync changes to any class in categories (package + tag) that begin with MyGemStone to the default session.
The class strategy can be overridden for an individual session by supplying the session with its own class strategy (GtGemStoneSessionCodeSync>>#classStrategy:
).
Further information on the available class and session strategies is available below.
Event Strategy
After a change is made to the code and sent to the session to be synchronised with the GemStone database, the event strategy (GtGemStoneCodeSyncEpEventStrategy
) determines what to do with the change.
Currently there are two event strategies:
GtGemStoneCodeSyncEpEventStrategy
:
synchronises method additions, modifications and removals
synchronises class additions, modifications and removals
synchronises class comments and category changes
renaming a class creates the new class but leaves the class with the old name untouched
ignores all other changes
GtGemStoneCodeSyncBasicEpEventStrategy
:
synchronises method additions, modifications and removals
ignores all other changes
Class Strategy
GtGemStoneCodeSyncCategoriesStrategy
will sync any class that is in one of the listed categories. Categories are matched using wild card strings, e.g. GemStone-classes-* would match any category beginning with GemStone-classes-*.
GtGemStoneCodeSyncCategoriesStrategy new categories: #('GemStone-classes-*')
GtGemStoneCodeSyncCustomClassStrategy
matches the class and session using the supplied valuable, e.g. a BlockClosure
.
GtGemStoneCodeSyncCustomClassStrategy new valuable: [ :aClass :aGtGemStoneSessionRegistry | aClass isKindOf: #PersistentObject asClass ]
GtGemStoneCodeSyncExplicitClassStrategy
syncs only the classes in the configure list. Note that this should be used with care since renaming the class to something outside the list will cause it to no longer be synced.
GtGemStoneCodeSyncExplicitClassStrategy new classes: { #CommonClass1. #CommonClass2. }.
GtGemStoneCodeSyncSubclassClassStrategy
syncs all subclasses of the supplied class. E.g:
GtGemStoneCodeSyncSubclassClassStrategy new superclass: #PersistentObject asClass
Session Strategy
GtGemStoneCodeSyncDefaultSessionStrategy
will only sync changes to the default session in the registry.
GtGemStoneCodeSyncDefaultSessionStrategy new
GtGemStoneCodeSyncExplicitSessionStrategy
will sync to all of the configured GemStone sessions.
GtGemStoneCodeSyncExplicitSessionStrategy new sessions:
{ GtGemStoneSessionRegistry default defaultSession }
Committing changes
GtGemStoneCodeSync
never commits a transaction.