bitflicker64 opened a new issue, #3066:
URL: https://github.com/apache/hugegraph/issues/3066
## Source
- **File:**
`hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/io/HugeGryoModule.java`
- **References:** L151-L152
---
Now I have a clear picture of the issue. Let me summarize what I found:
1. In `HugeGryoModule.java`, there are four Kryo serializer classes for
schema types:
- `PropertyKeyKryoSerializer`
- `VertexLabelKryoSerializer`
- `EdgeLabelKryoSerializer`
- `IndexLabelKryoSerializer`
2. Each of these has a `write()` method that is fully implemented (using
`GraphSONSchemaSerializer` to convert the schema object to a `Map<HugeKeys,
Object>`, then writing it via `writeEntry()`).
3. However, each `read()` method is a stub that just returns `null` with a
`// TODO` comment.
4. There's also a `readEntry()` helper method that exists but is marked
`@SuppressWarnings("unused")` — it's never called because the `read()` methods
are all stubs.
The issue is that:
- The Gryo (Kryo-based binary) serialization format is used for TinkerPop's
Gryo I/O (binary graph format)
- When deserializing schema objects from Gryo format (e.g., reading a graph
exported in Gryo format), all four schema type deserializers return `null`
instead of reconstructing the actual objects
- This means any code path that reads schema objects from Gryo binary format
will silently get `null` back, which could cause NullPointerExceptions or
incorrect behavior
The fix would require:
1. Implementing `readEntry()` usage in each `read()` method
2. But there's a complication: `GraphSONSchemaSerializer.writeVertexLabel()`
serializes property key names (strings) rather than IDs, and the `read()`
methods would need a `HugeGraph` reference to look up those names back to IDs —
which the Kryo `Serializer.read()` signature doesn't provide directly.
This is the same challenge that `HugeGraphSONModule` faces — it only
registers serializers (not deserializers) for schema types.
The `readEntry()` helper is already there and marked
`@SuppressWarnings("unused")`. The issue is that to reconstruct a `VertexLabel`
from the map, you need a `HugeGraph` reference (to resolve property key names
to IDs), which isn't available in the Kryo serializer context.
Files affected: Only 1 file directly contains the TODO stubs —
`HugeGryoModule.java`. But implementing the fix properly might require changes
to `GraphSONSchemaSerializer` to add read methods, or adding a way to pass the
graph context to the serializer.
Let me count the files that would need to change:
1. `HugeGryoModule.java` - the four `read()` methods need implementation
2. Possibly `GraphSONSchemaSerializer.java` - would need `readVertexLabel`,
`readEdgeLabel`, `readPropertyKey`, `readIndexLabel` methods (currently it only
has write methods)
Actually, looking at the existing code more carefully:
- `VertexLabel.fromMap()` exists and can reconstruct from a map
- `readEntry()` already exists in `HugeGryoModule.java` to read the map back
The problem is that `GraphSONSchemaSerializer.writeVertexLabel()` stores
property key names (strings), not IDs. So to reconstruct, you'd need a graph
reference to look up IDs from names. The Kryo serializer doesn't have access to
the graph.
So the fix would need either:
1. Store IDs instead of names in the write path (breaking change to
serialization format)
2. Pass the graph reference to the serializer somehow (e.g., via constructor)
3. Use a different approach
Actually, looking at `VertexLabel.fromMap()`, it works with IDs (integers),
not names. So the `GraphSONSchemaSerializer.writeVertexLabel()` format (which
uses names) is incompatible with `VertexLabel.fromMap()`.
The files affected would be:
1. `HugeGryoModule.java` - primary file with the TODOs (4 read methods)
2. Possibly `GraphSONSchemaSerializer.java` - if read methods need to be
added there
That's essentially 1-2 files directly, though the design challenge (needing
a graph reference) is the real blocker.
## The Issue
The problem is a **complete asymmetry between serialization and
deserialization** in the Gryo (Kryo-based binary) schema serializers. All four
schema-type Kryo serializers in `HugeGryoModule.java` have fully implemented
`write()` methods but stub `read()` methods that unconditionally return `null`.
### The four broken `read()` stubs
All four inner classes share the same pattern:
```java
// PropertyKeyKryoSerializer (line 151-154)
@Override
public PropertyKey read(Kryo kryo, Input input, Class<PropertyKey> c) {
// TODO
return null;
}
// VertexLabelKryoSerializer (line 165-168)
@Override
public VertexLabel read(Kryo kryo, Input input, Class<VertexLabel> c) {
// TODO
return null;
}
// EdgeLabelKryoSerializer (line 179-182)
@Override
public EdgeLabel read(Kryo kryo, Input input, Class<EdgeLabel> clazz) {
// TODO
return null;
}
// IndexLabelKryoSerializer (line 193-196)
@Override
public IndexLabel read(Kryo kryo, Input input, Class<IndexLabel> c) {
// TODO
return null;
}
```
### What the `write()` side does
Each `write()` method calls `GraphSONSchemaSerializer` to produce a
`Map<HugeKeys, Object>` (with **string names** for property keys, not IDs),
then serializes it via `writeEntry()`:
```java
public void write(Kryo kryo, Output output, VertexLabel vl) {
writeEntry(kryo, output, schemaSerializer.writeVertexLabel(vl));
}
```
There is even a `readEntry()` helper already written (but marked
`@SuppressWarnings("unused")` because nothing calls it):
```java
@SuppressWarnings("unused")
private static Map<HugeKeys, Object> readEntry(Kryo kryo, Input input) { ...
}
```
### The deeper design problem
The `read()` methods can't simply call `readEntry()` and reconstruct the
object, because:
1. `GraphSONSchemaSerializer.writeVertexLabel()` stores **property key
names** (strings), not numeric IDs.
2. Reconstructing a `VertexLabel` from names requires a `HugeGraph`
reference to resolve names back to `Id` objects — but the Kryo
`Serializer.read()` signature only provides `Kryo`, `Input`, and the target
`Class`. There is no graph context available.
3. `GraphSONSchemaSerializer` has **no `read*` methods at all** — it is
write-only.
Note: `HugeGraphSONModule` (the JSON counterpart) has the same gap — it only
registers serializers, not deserializers, for schema types.
### What needs to change
To fix this properly, **2 files** would be directly affected:
| File | Change needed |
|---|---|
| `HugeGryoModule.java` | Implement all 4 `read()` methods; pass a
`HugeGraph` reference via constructor to each serializer class |
| `GraphSONSchemaSerializer.java` | Add `readVertexLabel`, `readEdgeLabel`,
`readPropertyKey`, `readIndexLabel` methods that accept a `Map<HugeKeys,
Object>` and a `HugeGraph` and reconstruct the schema objects |
The `HugeGraphIoRegistry` or `register()` call site may also need a minor
touch to supply the graph reference to the serializer constructors, but the
core logic is confined to those 2 files.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
