Auto-generated ids from Marshallable are of type `Long` by default

[metasim]

I have some custom Marshallable implementations where I use FromCC(None, ..., ...). When I attempt to start a traversal with graph.V(0) I get an empty result. If I do graph.V(0l) it works, which now makes sense given the underlying implementation, but wasn't completely obvious why I was getting empty results. Is there some way to normalize across integral number types? Or explicitly set the type and allow TinkerPop to generate them. I'm not adept at Scala macros to understand all that's going on in gremlin.scala.Marshallable.

[metasim]

PS: I tried overriding the Id type member in Marshallable, but its constrained:

    Error:Error:line (56)overriding type Id in trait Marshallable, which equals AnyRef;
 type Id has incompatible type
    override type Id = java.lang.Integer
                  ^

[mpollmeier]

unfortunately we are constrained by the underlying tinkerpop behaviour in this one. maybe we can use another thought i had earlier to workaround this one: each graph implementation (orient, titan, neo4j, ...) has a specific id type, e.g. for orient it's always String. We could capture that as a type parameter of Graph and then enforce to always specify the right type. In your example, the compiler would automatically convert the Int to a Long and you wouldn't even notice.

Thoughts?

[metasim]

OK, good to know. I thought it might be in the macro instead of in TinkerPop since the TinkerFactory.createModern() has Integer ids, but certainly wasn't sure.

Seems to me that adding another type parameter (to ScalaGraph?) would be a drag and possibly a breaking change(?). It's a shame TinkerPop doesn't attempt to typecheck the ids in ...tinkerpop...Element.

Maybe just a note in the documentation under case class serialization?