bitflicker64 opened a new issue, #3065:
URL: https://github.com/apache/hugegraph/issues/3065
## 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 also check if there's a
`readEntry` helper that's already implemented but unused, and look at how the
GraphSON module handles deserialization for schema types to understand what a
proper implementation would look like.
The key facts:
1. `HugeGryoModule.java` has 4 schema Kryo serializers:
`PropertyKeyKryoSerializer`, `VertexLabelKryoSerializer`,
`EdgeLabelKryoSerializer`, `IndexLabelKryoSerializer`
2. Each has a `write()` method that works correctly (uses
`GraphSONSchemaSerializer` to produce a `Map<HugeKeys, Object>` and writes it
via `writeEntry()`)
3. Each has a `read()` method that is a stub returning `null` with a `//
TODO` comment
4. There's already a `readEntry()` helper method in `HugeGryoModule` that is
marked `@SuppressWarnings("unused")` — it reads back the `Map<HugeKeys,
Object>` from the Kryo stream, but it's never called
5. The `GraphSONSchemaSerializer` only has `write*` methods, no `read*`
methods — so to reconstruct schema objects from the map, you'd need to look at
how the backend serializers do it (e.g., `TextSerializer`, `BinarySerializer`)
The issue is specifically about the `read()` methods being unimplemented
stubs. The TODO note in the user's question specifically calls out
`PropertyKeyKryoSerializer.read()` but all 4 schema serializers have the same
problem.
The `readEntry()` helper is already there and marked
`@SuppressWarnings("unused")` — it can read back the map. But to reconstruct a
`PropertyKey` from the map, you'd need a `HugeGraph` reference (to look up IDs,
etc.), which the Kryo `read()` signature doesn't provide directly.
This is a significant design challenge: the Kryo `read()` method signature
is `read(Kryo kryo, Input input, Class<T> clazz)` — there's no `HugeGraph`
parameter. The backend serializers' `readPropertyKey(HugeGraph graph,
BackendEntry entry)` require a graph reference.
So the fix would need to either:
1. Store a `HugeGraph` reference in the serializer at construction time
2. Or use a different approach to reconstruct the schema objects
Let me check how many files would be affected. The issue is only in
`HugeGryoModule.java` — all 4 TODO stubs are in that single file. But to
implement the fix properly, you might also need to add read methods to
`GraphSONSchemaSerializer` or create a new helper.
Let me also check if there's any code that actually calls these `read()`
methods to understand the impact of them returning null.
Now I have a comprehensive picture. Let me summarize the issue clearly.
The core problem:
1. `HugeGryoModule.java` has 4 Kryo serializers for schema types:
`PropertyKeyKryoSerializer`, `VertexLabelKryoSerializer`,
`EdgeLabelKryoSerializer`, `IndexLabelKryoSerializer`
2. Each has a working `write()` method that serializes via
`GraphSONSchemaSerializer` → `Map<HugeKeys, Object>` → Kryo binary stream
3. Each has a `read()` method that is a stub returning `null` with `// TODO`
4. The `readEntry()` helper already exists in `HugeGryoModule` (marked
`@SuppressWarnings("unused")`) — it can deserialize the `Map<HugeKeys, Object>`
back from the Kryo stream, but is never called
The key structural challenge for implementing `read()`:
- The Kryo `Serializer.read(Kryo, Input, Class<T>)` signature doesn't
provide a `HugeGraph` reference
- The `write()` methods in `GraphSONSchemaSerializer` serialize property
names (strings) for things like `PROPERTIES`, `PRIMARY_KEYS`, etc. — so to
reconstruct the schema objects, you'd need to look up IDs from names, which
requires a `HugeGraph` reference
- However, looking at the `write()` output for `PropertyKey` specifically:
it writes `HugeKeys.ID` (as long), `HugeKeys.NAME` (string),
`HugeKeys.DATA_TYPE`, `HugeKeys.CARDINALITY`, `HugeKeys.AGGREGATE_TYPE`,
`HugeKeys.WRITE_TYPE`, `HugeKeys.PROPERTIES` (list of property key names),
`HugeKeys.STATUS`, `HugeKeys.USER_DATA`
- To reconstruct a `PropertyKey`, you need a `HugeGraph` reference to look
up property key IDs from names (for the `PROPERTIES` field)
The `readEntry()` helper is already there and unused. The fix would need to:
1. Pass a `HugeGraph` reference into the serializer constructors
2. Call `readEntry()` in each `read()` method
3. Reconstruct the schema object from the map
The scope of the fix is **1 file**: `HugeGryoModule.java`. Possibly also
`GraphSONSchemaSerializer.java` if read methods are added there. But the TODO
stubs are all in `HugeGryoModule.java`.
Note: The TODO comment in the user's question specifically calls out
`PropertyKeyKryoSerializer.read()`, but the same issue exists for all 4 schema
serializers in the same file.
Files affected: **1 file** (`HugeGryoModule.java`) contains all 4 stubs. If
`GraphSONSchemaSerializer` needs read methods added, that's a 2nd file. But the
core issue is in 1 file.
## The Issue
The problem is broader than just `PropertyKeyKryoSerializer` — **all four**
schema Kryo serializers in `HugeGryoModule.java` have unimplemented `read()`
stubs:
```java
// HugeGryoModule.java, lines 151-154
@Override
public PropertyKey read(Kryo kryo, Input input, Class<PropertyKey> c) {
// TODO
return null;
}
```
The same pattern repeats for `VertexLabelKryoSerializer` (line 165),
`EdgeLabelKryoSerializer` (line 179), and `IndexLabelKryoSerializer` (line 193).
This means **Gryo (Kryo-based) deserialization of schema objects silently
returns `null`**. Any code path that reads a `PropertyKey`, `VertexLabel`,
`EdgeLabel`, or `IndexLabel` from a Gryo-encoded stream will get `null` back,
likely causing a `NullPointerException` downstream.
---
## What the `write()` side does
Each `write()` delegates to `GraphSONSchemaSerializer`, which produces a
`Map<HugeKeys, Object>`, then writes it via the `writeEntry()` helper:
```java
// HugeGryoModule.java, lines 146-148
@Override
public void write(Kryo kryo, Output output, PropertyKey pk) {
writeEntry(kryo, output, schemaSerializer.writePropertyKey(pk));
}
```
The `writeEntry()` writes the map size, then each `HugeKeys` key and its
value:
There is already a symmetric `readEntry()` helper that reads this format
back — but it is **never called** (hence the `@SuppressWarnings("unused")`
annotation):
```java
// HugeGryoModule.java, lines 131-141
@SuppressWarnings("unused")
private static Map<HugeKeys, Object> readEntry(Kryo kryo, Input input) {
int columnSize = input.readInt();
Map<HugeKeys, Object> map = new LinkedHashMap<>();
for (int i = 0; i < columnSize; i++) {
HugeKeys key = kryo.readObject(input, HugeKeys.class);
Object val = kryo.readClassAndObject(input);
map.put(key, val);
}
return map;
}
```
---
## The structural challenge
The Kryo `Serializer.read()` signature is:
```java
T read(Kryo kryo, Input input, Class<T> clazz)
```
It provides no `HugeGraph` reference. But reconstructing schema objects from
the map requires one — for example,
`GraphSONSchemaSerializer.writePropertyKey()` stores property names (strings)
for the `PROPERTIES` field, and converting those names back to `Id`s requires a
graph lookup:
---
## What needs to change
**Only 1 file contains the stubs**: `HugeGryoModule.java`. However, fixing
it properly requires:
1. **`HugeGryoModule.java`** — the primary file. Each serializer class needs
a `HugeGraph` field injected at construction time (since the Kryo `read()`
signature doesn't supply it), and each `read()` must call `readEntry()` then
reconstruct the schema object from the resulting `Map<HugeKeys, Object>`.
2. **`GraphSONSchemaSerializer.java`** (optional, 1 file) — read methods
could be added here to mirror the existing `write*` methods, keeping the logic
centralized. Currently this class has no `read*` methods at all.
**Total files directly affected: 1–2.** The stubs are all co-located in
`HugeGryoModule.java`. The `register()` call site that constructs the
serializers would also need updating to pass a `HugeGraph` reference, but that
is still within the same file.
--
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]
