vertex types, property encoding

[Ilya Kardailsky]

Hi guys,

I've started playing around with the pacer-orient gem and have converted our project to use OrientDB instead of Titan, it's working great. Also thanks for the Pacer documentation, it's definitely cleared up a few things for me.

I've added a bit of code on my branch to query vertices and edges by OrientDB Class in the full-graph index route and I would be keen to make a pull request but I'm not sure what to name this property. Neo4j and Titan call it a 'label', OrientDB calls it a 'class', I get the impression Pacer usually refers to this as a vertex 'type' as you mention in the documentation and pacer-orient methods. Are you keen to keep the semantics of each graph backend or refer to it by something consistent? I'd lean towards having vertex labels to complement edge labels, as the TinkerPop people are doing, but in Orient it seems it's possible to have an edge Class and label at the same time which further muddies the water. Plus having a 'class' property is probably bad Ruby.

Also on a different topic, I've been converting my times to UTC in my graph encoders because time zone support varies a bit. I want to be able to filter my traversals with time comparisons, and automatically index/sort by time on the database layer. Is this something we want to do consistently? Titan/Neo4j are using the YAML encoder which does not have comparable serialised time strings (if timezone differs), Orient is using java Date/Time which don't track timezone, and Orient's binary encoder doesn't work with Pacer filters.

I've also been converting Symbol property values to Strings (and not converting them back on decoding), are you keen to try and keep those consistently typed? I ran into problems serialising and loading Sets of Symbols to and from Orient's Java store.

Cheers,

Ilya

[Darrick Wiebe]

Hi Ilya,

It's great to hear that the pacer-orient gem's working well for you!

If you've got a branch that you can point me to that has the code for the orient class functionality, I'd be interested to see it. We've been thinking about doing exactly that, too. This may actually be something worth folding into Blueprints/Pipes for the 2.7 or 2.8 release.

Encoders work better with the DateTime or Date classes rather than the Time class, especially when time zone is important. Have you tried using them? Improved support for date/time with time zones is relatively recently added, and I think only the YAML encoder really does that well at this moment. The other encoders really need to be updated. One of the things that has held things back is inability to support Java 8 (with its better date/time handling), waiting for Neo4j support to land. Now that has happened, I hope we'll manage dates much better very soon.

For the last issue, it may be that the Orient encoder is not properly recursively encoding Set elements. If you want to fix that, a pull request would be appreciated. If you're doing something custom, it's easy to derive an encoder from an existing one.

Cheers,

Darrick

--
You received this message because you are subscribed to the Google Groups "pacer-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pacer-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ilya Kardailsky]

Hi Darrick,

I've been working on https://github.com/mrbotch/pacer-orient

It's a very OrientDB-specific solution since it's just adding to the SQL index query rather than going through the Blueprints interface, I'm pulling out the property named 'label', not particularly elegant. I think it would be good to have a Blueprints-based solution, I believe they are making vertex labels first-class citizens in TP3 but I haven't been following their progress. I'm happy to make a pull request and tidy it up if you want.

The default Date/Time decoders in Orient is actually converting times and dates to UTC on decoding rather than encoding, which I think might be a bit backwards. When I use the binary encoders (which try to preserve timezone on Time) and try to run comparison traversals (using 'where' steps with a date) on binary-encoded Time objects I get

Java::JavaLang::ClassCastException: [B cannot be cast to java.lang.Comparable

from com.tinkerpop.blueprints.Compare.evaluate(com/tinkerpop/blueprints/com/tinkerpop/blueprints/Compare.java:25)

I'm not sure if using DateTime will help here because they are all being converted to java bytes.

The symbol/Set problem was actually when I tried to have #where filter steps executing some ruby code involving the symbols or comparing values in traversals. The recursion's actually working correctly:

g.encode_property Set[:a,:b:c]

#<HashSet: {byte[4, 8, 58, 6, 97]@4a14edc4, byte[4, 8, 58, 6, 98]@2c28414b, byte[4, 8, 58, 6, 99]@65f653f0}>

The Ruby interpreter just doesn't like Java's byte syntax after encoding variables for the comparison and complains about the @. Also:

Marshal.dump(:a).to_java_bytes == Marshal.dump(:a).to_java_bytes

Returns false, since JRuby doesn't seem to support comparisons for Java byte values either.

So I've been converting all symbols to strings, Date/Time to UTC, and typecasting them back to the correct datatype and timezone in my application, no big deal as I'm using Rails and need to have an ORM anyway. But I guess it would be nice if we could encode and decode things with impunity!

Thanks,

Ilya