[Bug] Preserve typed DEFAULT_VALUE and struct userdata after JSON reload

[dpol1]

Bug Type (问题类型)

logic (逻辑设计问题)

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• Server Version: 1.7.0
• Backend: schema metadata reload paths; not backend-specific
• OS: N/A
• Data Size: N/A

Expected & Actual behavior (期望与实际表现)

Expected

Userdata.DEFAULT_VALUE (~default_value) should preserve the expected runtime type after schema metadata is serialized and reloaded.

For example, a PropertyKey with DataType.DATE should reload its default value as java.util.Date, not as a generic JSON String.

Actual

Schema userdata is deserialized through raw Map / Object paths, so Jackson cannot infer the original runtime type.

For ~default_value, a Date default value can be serialized as a formatted string and later reloaded as String.

This may affect multiple schema reload paths, including:

• SchemaMetaManager -> PropertyKey.fromMap(...)
• JSON-based backend serializers such as Text/Binary/Table/Cassandra-style userdata reload paths
• the mirror userdata model in hugegraph-struct

Possible fix direction

PropertyKey already knows its dataType, so ~default_value could be normalized after the PropertyKey is reconstructed, using the same conversion logic already used for property values.

Scope

• Investigate Userdata.DEFAULT_VALUE reload behavior, especially for DataType.DATE.
• Normalize confirmed typed default values after schema reload.
• Check whether the same gap exists in hugegraph-struct.
• Add regression tests for the confirmed reload path(s).

Vertex/Edge example (问题点 / 边数据举例)

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

[dpol1]

@dosu could you check whether this issue is a valid follow-up for typed userdata reload handling, especially Userdata.DEFAULT_VALUE and hugegraph-struct?

[dosubot]

Yes, this is a valid follow-up issue. Here's why:

The gap is real. Userdata.DEFAULT_VALUE (~default_value) is defined in both hugegraph-core [1] and hugegraph-struct [2]. PropertyKey stores default values in the userdata map via defineDefaultValue() / defaultValue() [3], and PropertyKey.fromMap() deserializes userdata — including ~default_value — as raw Map<String, Object> [4]. This means a DataType.DATE default value will be reloaded as a String, exactly the same root cause as the ~create_time bug in #3013 [5].

Relationship to #3013. Issue #3013 established that all backend serializers deserialize userdata into a raw Map, so formatted timestamps are never converted back to Date. The fix direction discussed there (normalizing in SchemaElement.userdata(String, Object)) would naturally cover ~create_time but would not cover ~default_value, because ~default_value's expected type depends on PropertyKey.dataType() rather than being unconditionally Date. That makes this a distinct follow-up requiring its own type-aware normalization step — likely in PropertyKey.fromMap() or PropertyKey.defaultValue() after the data type is known.

hugegraph-struct scope. The hugegraph-struct module has its own parallel Userdata and PropertyKey classes [6] [7] used for distributed RPC communication [8]. If hugegraph-struct's PropertyKey also deserializes from maps or JSON without type-aware normalization, the same gap would exist there as well.

Summary: This is a valid, distinct follow-up to #3013 — same class of bug (userdata type loss on reload), but requires a different fix because the expected type of ~default_value is dynamic (driven by dataType) rather than static.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[dpol1]

@dosubot What exact role does hugegraph-struct's PropertyKey / Userdata model play in schema serialization or RPC flows, and should the DEFAULT_VALUE normalization be duplicated there or kept only server-side?

[dosubot]

Good question. Here's what hugegraph-struct's PropertyKey / Userdata actually does and where normalization should live:

Role in the architecture: hugegraph-struct's PropertyKey is used by hugegraph-store (the distributed storage layer) to reconstruct schema metadata retrieved from hugegraph-pd. Schema elements are not protobuf messages — they flow as JSON through PD's generic KV service [1]. The store deserializes them via PropertyKey.fromMap() [2] and then uses the reconstructed PropertyKey as a codec descriptor to guide binary encoding/decoding of property values in RocksDB [3].

The conversion path:

hugegraph-core PropertyKey → asMap() → JSON → PD KV store
                                                    ↓
hugegraph-struct PropertyKey ← fromMap() ← JSON ← PD retrieval

There is no direct converter between the two PropertyKey classes — conversion is implicit through JSON [4]. This is the exact point where type information is lost: fromMap() stores userdata values as-is from the deserialized Map<String, Object>, with no type-aware normalization [5].

Where normalization is needed: Both sides need it, but for different reasons:

1. hugegraph-core (server-side): Needed when the server itself reloads schema from backend storage or PD after cache invalidation. The existing serializers (Text/Binary/MySQL/Cassandra) all deserialize userdata into raw maps [6]. This is the same path that causes the ~create_time issue in [Bug] schema ~create_time userdata round-trips Date as String after cache reload #3013.

2. hugegraph-struct (store-side): Needed because PropertyKey.fromMap() reconstructs from JSON with no type conversion on userdata [7]. If the store ever calls defaultValue() and uses the result — for example to fill missing property values during binary encoding — it would get a raw String instead of the expected typed value.

Recommendation: The normalization should exist in both modules, ideally as a shared pattern. The natural location is in PropertyKey.defaultValue() itself (or immediately after fromMap() sets the data type), since that's where dataType is known and can drive the conversion. The struct version already has validValue() / convValue() methods that do type conversion [8] — those could be reused:

public Object defaultValue() {
    Object val = this.userdata().get(Userdata.DEFAULT_VALUE);
    if (val != null) {
        val = this.validValue(val);  // normalize using dataType
    }
    return val;
}

This avoids duplicating conversion logic and keeps both modules consistent. Since the two PropertyKey classes have nearly identical implementations, the same fix pattern applies to both [9] [10].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.