Challenge Objectives

Create Spring Data plugin for the OrientDB 
 

Project Background

OrientDB is the first Multi-Model Open Source NoSQL DBMS that combines the power of graphs and the flexibility of documents into one scalable, high-performance operational database.

Gone are the days where your database only supports a single data model. As a direct response to polyglot persistence, multi-model databases acknowledge the need for multiple data models, combining them to reduce operational complexity and maintain data consistency. Though graph databases have grown in popularity, most NoSQL products are still used to provide scalability to applications sitting on a relational DBMS. Advanced 2nd generation NoSQL products like OrientDB are the future: providing more functionality and flexibility, while being powerful enough to replace your operational DBMS.
 
There is an existing spring data plugin for OrientDB: https://github.com/orientechnologies/spring-data-orientdb, but it’s outdated and no longer working with latest OrientDB. 

It’s intended to create a fresh Spring Data plugin based upon the latest OrientDB API rather than update this outdated plugin. 
 

Technology Stack

• Spring Data 2.2.0
• OrientDB 3.0.23
• Java 1.8 (Oracle)
• Maven 3.6.2

 

Requirements

Create Spring Data Plugin for the OrientDB, the plugin should be based upon Multi-Model API.

The Spring Data Plugin should support following features:

• The following entity level annotations should be supported:
  • @ElementEntity - map the pojo to an OElement
    • an optional name attribute should be supported, if provided, use it to create the class, otherwise use the class name. 
    • If a property is marked as transient, it won't be saved to the database. 
    • Please check this link to see all the types to be supported: http://orientdb.com/docs/3.0.x/general/Types.html
      • You can ignore the CUSTOM and ANY types
    • @Embedded annotation for property of pojo object
      • If it's single object, it's treated as Embedded type, and depending upon it's List/Map/Set, it's treated as EmbeddedList, EmbeddedMap, or EmbeddedMap automatically. 
    • If the property of pojo object is not annotated. 
      • If it's a single object, it's treated as Link type, and depending upon it's List/Map/Set, it's treated as LinkList, LinkMap or LinkSet
      • The pojo object is treated as OElement. 
    • The property constraints should be supported: http://orientdb.com/docs/3.0.x/java/Document-API-Property.html#working-with-constraints
  • @VertexEntity - map the pojo to an OVertex
    • all rules from @ElementEntity applies here (except the ones below)
    • For the property of pojo  that is not annotated, it's treated as Edge
      • an optional @Edge annotation can be provided, with an optional name attribute. The property name (with 1st character upper-cased) is treated as the Edge class if the @Edge's name attribute is not provided, otherwise use Edge's name attribute. 
      • The pojo object is treated as OVertex
  • @EdgeEntity - map the pojo to an OEdge
    • all rules from @ElementEntity applies here
    • it seems it can only support basic types and Embedded types. 
• Schema Generation
  • add a flag in property file to auto generate the schema or not. 
  • if it's on. please generate the class as well as the property schema
  • it should scan all the annotated POJOs to generate the schema. 
  • There can be cyclic references, this should be handled propertly
• Class inheritance should be supported: http://orientdb.com/docs/3.0.x/general/Inheritance.html
• Repository with the following features:
  • CRUD support
    • ���It's very expensive to convert the OrientDB data object to and from the POJO, and especially when a node links with many other nodes, and the other nodes link to many other nodes. So it's expected the load method should return a proxy object with lazy loading (just like the Multi-Model / Object API). 
  • Paging and Sorting
  • Query and Find Support - it’s not in scope, it will be covered in next challenge, and your submission should be extensionable enough to make it easy
    • e.g. findByXXX - you can refer to this neo4j reference guide for some examples. We expect similar things for OrientDB
    • Annotated Queries - user can specify raw query with @Query annotation directly
• Transaction - it should work with Spring's @Transactional
• All necessary configuration of OrientDB and ODatabaseDocument

Note that if anything I mentioned is wrong, or there is a better approach, please raise it in the forum. 
We also provide a submission from previous failed challenge in the forum, it gets something right, and you can learn from it. 

Final Submission Guidelines

Submission Deliverable

• Source code
• Simple Accuracy tests
• A demo for nodes of this demo db: http://orientdb.com/docs/3.0.x/gettingstarted/demodb/
• README.md file with clear deployment guide and verification guide