search

orientechnologies / orientdb-gremlin

TinkerPop3 Graph Structure Implementation for OrientDB
Apache License 2.0
91 stars 32 forks source link

gremlin 3.2.2 and orient 2.2.9 #94

Closed mpollmeier closed 7 years ago

coveralls commented 8 years ago

Coverage Status

Coverage remained the same at 84.071% when pulling fe6287348e4ec62119871a565bc65a8eda6958b3 on 3.2.2.0 into 60be76bc687b4ad418069478ed9c0482f7132c53 on master.

coveralls commented 8 years ago

Coverage Status

Coverage remained the same at 84.071% when pulling fe6287348e4ec62119871a565bc65a8eda6958b3 on 3.2.2.0 into 60be76bc687b4ad418069478ed9c0482f7132c53 on master.

coveralls commented 8 years ago

Coverage Status

Coverage remained the same at 84.071% when pulling 6ecd0c72b3e20eb9d52ff1493fbee16bea09cc83 on 3.2.2.0 into 60be76bc687b4ad418069478ed9c0482f7132c53 on master.

mpollmeier commented 8 years ago

@velo can you help me out? the test errors are related to the JsonSerialisation - there've been a few changes in tinkerpop 3.2.2 apparently. Here's one of the errors: expected:<v[#9:0]> but was:<v[{@class=com.orientechnologies.orient.core.id.ORecordId, clusterId=9, clusterPosition=0}]

I.e. the id is serialised differently, or they compare our simple string id with the json serialised id? Do you have any ideas on what to do best about those IO tests?

you can reproduce the exact errors travis reports with mvn test -Dtest=OrientGraphStructureStandardIT -Dfailsafe.timeout=0

A more simple test we have to test the serialisation is OrientIoRegistryTest.

coveralls commented 8 years ago

Coverage Status

Coverage remained the same at 84.071% when pulling 829f1f0e2c954b83eeb3a11f306fc5e9ba9518da on 3.2.2.0 into 60be76bc687b4ad418069478ed9c0482f7132c53 on master.

velo commented 8 years ago

ok, looking

mpollmeier commented 7 years ago

fixed in https://github.com/mpollmeier/orientdb-gremlin/pull/103