Releases: atlanmod/NeoEMF
v2.1.0
version 1.0.3
Just a maintenance release to solve a security flaw caused by Log4j
v2.0.0
2.0.0
Released on 2019-03-21.
IMPORTANT NOTE: Due to significant changes in data mapping, databases created with a previous version are not compatible with this release.
No migration helper is provided: the simplest way to transfer the old databases to the new ones, is to export the database into an XMI file and re-import it.
NOTE: The changelog of this version is not exhaustive and regroup only major changes.
Core
- [NEW] Use
ServiceLoader
and OSGI Services to retrieve implementations ofConfig
,BackendFactory
andUriFactory
- [NEW]
Id
instances are created by anIdProvider
instead of static methods - [UPD]
Id
s use along
representation, or a 64-bits word. They can be converted to a hexadecimal string and vice versa to maintain compatibility withBackend
s that don't supportlong
- [UPD] The hasher used to generate new
Id
from a value is now xxHash that provides better performance than MurmurHash3 - [UPD] Features are identified by their
EStructuralFeature#getFeatureId()
instead of their name (seeFeatureBean
)
Back-ends and stores abstraction
- [NEW] Introduce the new
DataMapper
layer to manipulate elements as key/value pairs.
They are presented as several interfaces and each have their responsibility:ContainerMapper
: manage the container of elements (represented byContainerBean
)ClassMapper
: manage the meta-class of elements (represented byClassBean
)ValueMapper
: manage single-valued attributes of elements (identified bySingleFeatureBean
)ReferenceMapper
: manage single-valued references between elements (identified bySingleFeatureBean
)ManyValueMapper
: manage multi-valued attributes of elements (identified byManyFeatureBean
)ManyReferenceMapper
: manage multi-valued references between elements (identified byManyFeatureBean
)
- [NEW] Several default mappings have been implemented to process references as attributes after a conversion, or to manage data with indices, arrays, lists, or with a custom way.
They are presented as interfaces to allow a combination of several mappings.
For example, you can combine:ReferenceAs<String>
,MergeManyReferenceAs<String>
andManyValueWithLists
. These mappings are optional - [NEW] A generic
DefaultTransientBackend
has been created to handle transient elements in memory:
CustomTransientBackend
s are no longer necessary, but this requires theneoemf-io
module to transfer the transient content to aPersistentBackend
- [NEW]
URI
s are now created with factories instead of static methods - [UPD] Complete optimization of all existing database adapters
- [UPD]
Backend
s are auto-closed when the JVM is shutting-down - [UPD]
StoreAdapter
become the onlyEStore
implementation, and provides a bridge between EMF andDataMapper
s - [UPD] All
Backend
s andStore
s inherit from theDataMapper
architecture - [UPD] Back-end configuration have been merged, updated and simplified
- [UPD] Configuration is now managed with a simple
Properties
file (may change in the near future) - [UPD]
PersistentResource
are no longer linked to theirBackend
s, prefer usingStore
s - [UPD]
BackendFactory#createBackend()
take aURI
as parameter instead of aFile
to handle distributedPersistentBackend
- [DEL] All backend-specific implementations of
PersistentStore
have been merged with those atcore
-level - [DEL]
InvalidStore
has been replaced byInvalidBackend
- [DEL]
TransientStore
s have been removed and replaced byBoundInMemoryBackend
(a lightweigth and shared version of anDefaultInMemoryBackend
)
Automation
- [NEW]
BackendFactory
s are automatically registered at runtime (no need to explicitly register them in theResourceSet
registry) - [NEW]
BackendFactory
s are linked to their associatedUriFactory
andConfig
with annotations which are processed at runtime: aUriFactory
orConfig
can be retrieved from their association - [NEW] Stores and mappings are created by using reflection in
BackendFactory
to allow customizations (defined withConfig
) - [NEW]
URI
s are automatically created according to a common prefix ("neo-") and the lowercase name of their associatedBackendFactory
I/O
- [NEW] The direct-import becomes generic and works with all implementations
- [NEW] The direct-export is fully implemented, and is possible to an XMI file (compressed or not), or another
DataMapper
Performance
- [NEW] Add batch methods
getAll
,setAll
,... in addition toget
,set
,... to avoid multiple call - [UPD]
BlueprintsBackend
s labels has been simplified by one-letter labels - [UPD] The default chunk of
AutoSaveStore
is processed automatically from the total amount of memory - [UPD] Map-based
Serializer
s have been replaced by generic serializers (the implementation is located inatlanmod:commons-core
and use FST)
Utility methods
- [DEL] Utility classes and methods have been moved to
atlanmod:commons-core
Tests
- [NEW] All mappings have a code coverage of ~100% to ensure the expected behavior of future implementations
- [NEW] HBase is now integrated in tests by using an Hadoop mini-cluster (requires Cygwin on Windows)
- [UPD] Test helpers have been merged and simplified: now only a link to
Context
is needed for multi-backend tests - [UPD] Models used in
io
test-cases are now generated with Maven during the compilation - [UPD] Tests have been migrated to JUnit5
Benchmarks
- [NEW] Use
NEOEMF_HOME
system variable to locate the base benchmark directory - [UPD] The NeoEMF database are created using the
io
importer instead of the standard importer - [NEW]
Store
s can be configured in benchmarks, with thes
parameter - [UPD]
Adapter
s are configured with thea
parameter (previouslyb
)
Miscellaneous
- [NEW]
FeatureMap
support (still not supported by theneoemf-io
module) - [NEW] Some methods use
Optional
instead of a comparison tonull
- [UPD] Complete review of EMF collections to handle massive iterations
- [FIX] Issue #11: The
LoggingStoreDecorator
now use a dedicatedLogger
for its associatedBackend
- [FIX] Issue #12: The stores are updated according to the EMF calls, so that the backends are always synchronized.
There is no longer custom processing duringset()
andadd()
- [FIX] Issue #15: The
blueprints.***.directory
property is overwritten in all cases by the current path:
If a datastore already exists, then this property is updated with the new path, otherwise, the property stay unchanged. - [FIX] Issue #27/#28:
Store
s are no longer copied when the associatedResource
is unloading: AResource
should not be called if it's not loaded - [FIX] Issue #57: The
Cache<Id, PersistentEObject>
is now common for all implementations - [FIX] Issue #58:
guava
dependencies are no longer used in the project - [FIX] Issue #63:
BasicReference
s are first processed asBasicAttribute
s when reading, then redirected inEcoreProcessor
which has access to its real type with theEPackage
- [FIX] Issue #64: If an
Id
is not found inBackend
s, then an empty array is returned - [FIX] Issue #70: The
LazyMatchEngine
class has been removed - [FIX] Issue #71:
BoundInMemoryBackend
are registered in a local registry to ensure that the features can be retrieved even if the associatedPersistentEObject
is freed from memory - [FIX] Issue #72: Ignore the uniqueness check of identifiers when creating a new
Vertex
- [FIX] Issue #73: The
neoemf-data-map-core
module no longer exists - [FIX] Issue #75: The
io
module now use theDataMapper
structure, and not a custom implementation - [FIX] Issue #77: Errors are intercepted and displayed in Eclipse UI
- [FIX] Issue #78: Improve the
NullPointerException
message - [FIX] Issue #80:
DefaultPersistentEObject.toString()
throws aStackOverflowError
onEClass
instances - [FIX] Issue #84:
FeatureMap
s was not supported
Refactoring
- [UPD]
PersistenceBackendFactory
becomeBackendFactory
: they also createTransientBackend
s - [UPD]
OptionsBuilder
becomeConfig
- [UPD]
PersistenceURI
becomeUriFactory
: static methods have been replaced by this factory - [UPD]
PersistentStore
becomeStore
: they don't have any state, so the "Persistent" prefix does not make sense - [UPD]
FeatureKey
becomeSingleFeatureBean
- [UPD]
MultiFeatureKey
becomeManyFeatureBean
- [UPD]
MetaclassValue
becomeClassBean
- [UPD]
ContainerValue
has been merged withSingleFeatureBean
Dependencies
- [NEW]
chronicle-map
:3.17.0
- [UPD]
com.sleepycat:je
:5.0.73
to18.3.12
(BerkeleyDB) - [UPD]
mapdb
:3.0.5
to3.0.7
- [UPD]
org.eclipse.emf
:2.12.0
to2.15.0
(including associated dependencies) - [UPD]
cglib
:3.2.4
to3.2.10
- [UPD]
log4j
:2.7
to2.11.1
- [UPD]
org.neo4j
:1.9.6
to2.1.8
(includeblueprints-neo4j-graph
toblueprints-neo4j2-graph
) - [DEL]
junit
: No longer needed, managed byatlanmod:commons-core
(`5....
v1.0.2
Summary
We fixed a set of bugs we found in our experiments and we received in users' feedbacks. Thanks for helping us improving the tool! We also integrated a new experimental integration with EMF Compare, allowing to compare NeoEMF models to other EMF-based models. This feature will remain experimental until the next major release that will remove conflicting Guava dependencies.
We also merged the common features of MapDB and BerkeleyDB backends to improve maintainability and reusability of map-based serialization components.
Changelog
New Features
- Add experimental EMF Compare integration (will stay experimental as
long as Guava issues remain)
Bug Fixes
- Fixed Issue #53: WildCardType '?' in sample (mapdb) throws an exception
when accessed in the Editor - Fixed Issue #54: AbstractDirectWrite.toArray is not efficient
- Fixed Issue #55: DefaultPersistentEObject.eContainer is not efficient
- Fixed Issue #56: Unnecessary backend lookups in Store.eObject(Id)
- Fixed Issue #68: Creating contained objects with Epsilon does not work
Back-ends
- Merge common code from MapDB & BerkeleyDB in Map module
- BerkeleyDB remains an experimental backend until the next major release
v1.0.1
Summary
Core modularization to ease new backend integration: all the supported backends are now defined as sub-project of the data
module. The Logger
has been updated to work in a dedicated thread, limiting its impact on the application performance. We have improved and rewritten a large part of the JavaDoc and published it on NeoEMF website. Tests are not modular and can be executed on all the supported backends, this allows to develop high quality implementations that benefit of existing tests. We also fixed few issues and updated the dependencies with the latest EMF release. See the changelog for a complete description of the updates.
Update Site
Changelog
Structure
datastore
packages becomedata
- Backend implementations are now placed under the
fr.inria.atlanmod.neoemf.data
package graph
package is replaced bydata
: no more structural differentiation in the package structure***Map***
classes representing the MapDB implementation are replaced by***MapDb***
- Generalization of
PersistenceURI
and its sub-classes - Addition of new common annotations:
@VisibleForTesting
and@Experimental
Logger
is now fully-concurrent and extensible: We can use different parallelLogger
s. However, these loggers keep the call order.- Generalization
BundleActivator
s
Back-ends
- Integration of a new key-value backend implementation: BerkeleyDB (experimental).
ClassInfo
andContainerInfo
have now static constructor methods:from()
andof()
Tests
- Contextualization of tests: One test-case can be executed by several back-end implementations according to the current
Context
defined by@Parameterized.Parameters
- Test-cases are now tagged
- Preparation of tests for a future integration of JUnit 5
- Externalization JUnit
Rule
s - Reorganization of
@After
/@Before
methods All***
classes becomeAbstract***
- Remove
NeoAssertions
class and its related customBuilder
s
Documentation
- JavaDoc has been completely revised and completed.
- Addition of new JavaDoc tags:
@future
and@note
Bug Fixes
- Fixed issue #51: Concurrent
Executor
inLogger
did not stop with the JVM - Fixed issue #52: Partial fix with a
try...catch
Dependencies
- Added OSGI dependency
org.osgi
:6.0.0
- Removed OSGI implementation dependency
org.eclipse.osgi
- Upgraded
org.eclipse.emf:***
dependencies from2.11.0
to2.12.0
v1.0.0
Initial release of the tool. Defines the core components of the framework and the supported backends.
Update Site
- Core API defninition
- Extension of the EMF API with PersistentResource and PersistentEObject
- Abstract backend architecture
- Support for persistent and transient backends
- Enhanced load/save mechanism to support NeoEMF options
- Support for Blueprints databases
- Complete model-to-Blueprints mapping
- Neo4j convenience wrapper
- Support for MapDB databases
- Support for HBase databases
- IO module
- Efficient XMI-to-Blueprints parser
- Benchmarks for all the supported backends
- Comparison with the default XMI serialization
- Comparison with CDO
- Model traversal queries