Want to live on the edge? OrientDB Labs is the place to be.
Here you can find all the latest and greatest features of OrientDB, our experiments, cutting edge articles and downloads
OrientDB v 3.0 was a chance to consolidate all our experience and to provide a really unified developer experience: improved storage engine, new MultiModel API, enhanced SQL query engine, support for TinkerPop 3.
Now it's time to move forward and unveil some of the new features that will be in OrientDB v 3.1:
OrientDB v 3.1 is a step forward to provide all the features you expect from an Operational Multi-Model database.
As always, we’d like to thank the relentless efforts on behalf of the entire OrientDB Community who have helped make this possible not only by providing feedback & reporting issues but by providing valuable integrations now officially supported in this latest release.
So go ahead and give our latest release a try, but remember, this is not a stable release and is not suitable for production environments.
As this is our milestones release, please submit all bugs or issues via Github.
*Official Documentation currently still under revision and subject to changes.
With OrientDB v 3.1 we are shipping some structural changes to the distributed module. In particular, the new distributed coordination algorithms remove the limitations related to cluster ownership.
The complete redesign of the distributed transaction model removes some legacy components and makes the behavior more predictable. This results in easier maintainability and improved stability.
A materialized view is just the result of a query, stored in a persistent structure and available for efficient querying.
Materialized views are something every developer knows and appreciates from Relational Databases, having them in OrientDB means having another tool to achieve even better performance.
Innovating also means learning from the best technologies of the past!
OrientDB still relies on optimistic locking for its standard transactional behavior. But now you have a chance to choose, when needed, to have a more direct and fine grained control on record locking, also in a distributed environment
In OrientDB v 3.1, the old record-level security based on record ownership is replaced by a much more flexible and powerful predicate security module (the legacy behaviour is still there for backward compatibility).
Security policies can be defined, with SQL predicates that define if a record operation (create, read, update, delete) can be performed on a record.
If the predicate is satisfied by the record and current session data (user, role), then the operation is allowed, otherwise it is not.
Eg. if the predicate defined on READ returns FALSE for a record and a user, then that record will be just hidded for that user.
Predicate security can also be applied to single properties, ie. a user could be able to see/update a subset of the properties in a document, OrientDB will automatically hide (or avoid to update) those that are not allowed.
OrientDB 3.1.0-beta1 is still under development.