Object API and Spring Data

At this point, it seems that the Orient Spring Data Module has been abandoned.

My question is fairly straight forward:
Is the Orient Object API compatible with Spring Data Commons?

There are discrepancies between the Object API and Spring Data Commons with respect to object mapping, specifically, object immutability.

In general, it’s not clear if there is anything which explicitly precludes the Object API to integrate with Spring Data?
The Orient Spring Data Module, other than using the deprecated APIs, looks like it should work if it were updated to use 3.x.

Any help appreciated!

I only know some details about the Object API because I’ve been fiddling with it a bit. The object API is a pretty old one and works by creating a proxy object implementing Javassist interface “MethodHandler”. The proxy object will have an ODocument instance inside it and the MethodHandler.invoke() method will determine by the getter/setter which property in ODocument it should access.
Having said that, these are its limitations:

  • Only setters & getters, the field values are not populated.
  • It doesn’t proxy interface classes like “java.lang.reflect.Proxy” can do.
  • It looks like it was designed & built when OrientDB was still only a document database, no edge support.
  • The entity name and POJO class name have to be identical, you can’t map an existing schema class to a different POJO class and also the upper/lower case has to match.
  • It can’t register a package with object classes when the reside inside a jar inside a war. (Instead Reflections can do that.)

(In a local version I have fixed all of the issues above and added several @Annotations in order to support what I need, but it’s still very experimental and has had a very narrow testing scope.)

1 Like

Thanks for the reply!
There are definitely some trade-offs to consider.
It sounds like, in spite of the limitations you’ve shared and the limited testing scope, that you are still using the API?

I am not sure yet whether I’m going to use (the altered version of the API) in production. It depends whether it works well / stable and I want to see if it can proxy Swagger generated classes and if the REST controller can handle those without problems. (The latter would be a good use case, be able to directly load db objects or object trees into a REST result model.)

The latter would be a good use case, be able to directly load db objects or object trees into a REST result model.

Nope.

That is an excellent use case!

If the proxy works, then swagger takes care of your JSON serialization/deserialization (unless I’m mistaken). In a pinch, you might take advantage of those JSON capabilities I’ve been trying to work towards :wink:

I’ve been eyeballing salary.toJSON()

create class Test extends V
insert into Test content {"attr1": "value 1", "attr2": "value 2"}

select @this.toJson('rid,version,fetchPlan:in_*:-2 out_*:-2') from Test

or like CREATE VERTEX,

CREATE VERTEX Employee CONTENT { "name" : "Jay", "surname" : "Miner" }

Seems like a straight-forward way to get JSON in/out of the db, selectively. I like it.
I’d love to hear how it goes!

I was looking at Object API with Spring in mind. It’s inspired by the defunct Orient Spring Data effort, and the realization that I can roll my own repo implementation. I want to create type-specific, runtime Spring “repositories” for each of the classes scanned by the Object API. Each repo bound to a single OrientDB class, running in a dedicated thread with a dedicated db instance.

Currently, I’m only making use of the package scanning. The automatic schema generation is nice.
The rest is WIP.

Thanks again for sharing!