Thanks for reporting this issue. The "Wrong field type" error looks like a bug to me. This happens, because PojoType is neither a TupleType nor an AtomicType. To me it looks like the TupleTypeInfoBase condition should be generalized to CompositeType.
I will look into this. Cheers, Fabian 2015-07-30 14:18 GMT+02:00 Gábor Gévay <[email protected]>: > Hello, > > I am having some trouble building a graph where the vertex ID type is > a POJO. Specifically, it would be a class that has two fields: a long > field, and a field which is of another class that has four byte > fields. (Both classes implement the Comparable interface, as the Gelly > guide specifies.) If the outer class has a default constructor, then > it is recognized as a POJO, but I get the following exception: > > Exception in thread "main" java.lang.IllegalArgumentException: Wrong > field type: PojoType<malom.GameState, fields = [board: Long, sid: > PojoType<malom.SectorId, fields = [b: Byte, bf: Byte, w: Byte, wf: > Byte]>]> > at > com.google.common.base.Preconditions.checkArgument(Preconditions.java:122) > at > org.apache.flink.api.java.operators.Keys$ExpressionKeys.<init>(Keys.java:241) > at > org.apache.flink.api.java.operators.Keys$ExpressionKeys.<init>(Keys.java:203) > at > org.apache.flink.api.java.operators.CoGroupOperator$CoGroupOperatorSets.where(CoGroupOperator.java:458) > at org.apache.flink.graph.Graph.inDegrees(Graph.java:701) > at > org.apache.flink.graph.spargel.VertexCentricIteration.createResultVerticesWithDegrees(VertexCentricIteration.java:610) > at > org.apache.flink.graph.spargel.VertexCentricIteration.createResult(VertexCentricIteration.java:180) > at org.apache.flink.api.java.DataSet.runOperation(DataSet.java:1044) > at > org.apache.flink.graph.Graph.runVertexCentricIteration(Graph.java:1312) > at malom.Retrograde.run(Retrograde.java:64) > at malom.Solver.main(Solver.java:32) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140) > > Note, that originally the exception just said "Wrong field type", from > which I had no idea what type is it referring to, so I modified line > 241 of Keys.java to include the type in the msg like this: > Preconditions.checkArgument(fieldType instanceof AtomicType, "Wrong > field type: " + fieldType.toString()); > > On the other hand, if I comment out the default constructor of the > outer class, then it is not a POJO, but only a GenericTypeInfo is > created from it, which implements AtomicType, so the previous > exception does not appear. Does this mean that the Vertex IDs cannot > be POJOs? I am not sure if this is the intended behaviour. After all, > if we have a POJO, that should always be better then if we have a > generic type, right? > > (I am just guessing here, but maybe CompositeType could also be > regarded as an AtomicType: the only method declared by the AtomicType > interface is createComparator, which is also defined in CompositeType > (of which PojoTypeInfo is a subclass), but with different parameters, > but maybe CompositeType could implement AtomicType by delegating the > createComparator call with all of the fields specified?) > > I encountered another problem, which is may or may not be related to > the above: without the default constructor (the GenericTypeInfo case), > the VertexCentricIteration "eats" my graph, that is, the result graph > has zero vertices. I traced this problem to the first join in > VertexCentricIteration.createResultVerticesWithDegrees, where the > "degrees" DataSet is created: both inputs of the join (outDegrees and > inDegrees) contains the correct data, but the result (degrees) is > empty. Interestingly, this problem disappears, if I add > JoinHint.REPARTITION_SORT_MERGE. > > Best regards, > Gabor >
