dpol1 opened a new issue, #3013:
URL: https://github.com/apache/hugegraph/issues/3013

   ### Bug Type (问题类型)
   
   logic (逻辑设计问题)
   
   ### Before submit
   
   - [x] 我已经确认现有的 [Issues](https://github.com/apache/hugegraph/issues) 与 
[FAQ](https://hugegraph.apache.org/docs/guides/faq/) 中没有相同 / 重复问题 (I have 
confirmed and searched that there are no similar problems in the historical 
issue and documents)
   
   ### Environment (环境信息)
   
   - Server Version: 1.0.0 (Apache Release Version)
   - Backend: RocksDB x nodes, HDD or SSD 
   - OS: xx CPUs, xx G RAM, Ubuntu 2x.x / CentOS 7.x 
   - Data Size:  xx vertices, xx edges <!-- (like 1000W 点, 9000W 边) -->
   
   
   ### Expected & Actual behavior (期望与实际表现)
   
   HugeGraph automatically writes internal schema userdata 
`Userdata.CREATE_TIME` (`"~create_time"`) as a `java.util.Date` when creating 
schema elements.                
      
     ### Expected                                                               
                                                                                
           
                                
     After a schema element is reloaded from backend storage, this value should 
still be a `java.util.Date`, consistent with existing schema tests that cast    
           
     `schemaElement.userdata().get(Userdata.CREATE_TIME)` to `Date`.
                                                                                
                                                                                
           
     ### Actual                 
   
     After a backend/store reload, 
`schemaElement.userdata().get(Userdata.CREATE_TIME)` can be returned as a 
`String` timestamp instead of `java.util.Date`.               
      
     This is exposed more clearly after PR #3011 because cross-JVM 
schema-cache-clear events cause remote server nodes to invalidate and reload 
schema from backend        
     storage. The publishing JVM may not observe the issue because it can keep 
using the in-memory schema object and, with the self-echo skip, does not reload 
its own
     freshly-created schema.                                                    
                                                                                
           
                                
     ### Suspected cause
   
     The schema userdata serialization path writes `Date` values as strings, 
but the schema deserialization path does not convert the internal 
`~create_time` value back to
      `java.util.Date`.
                                                                                
                                                                                
           
     ### Scope                  
   
     Out of scope for PR #3011. That PR only changes runtime schema-cache 
invalidation propagation. It does not change persisted schema data or fix 
schema userdata        
     serialization round-trips.
                                                                                
                                                                                
           
     ### Minimal repro sketch   
   
     1. Start two HugeGraph server JVMs sharing the same graph / meta / 
backend.                                                                        
                   
     2. On **Server A**, create a schema element (e.g. a property key or vertex 
label).
     3. Ensure **Server B** reloads that schema from backend storage after a 
schema-cache-clear event.                                                       
              
     4. On **Server B**, inspect 
`schemaElement.userdata().get(Userdata.CREATE_TIME)`.                           
                                                          
     5. **Expected type:** `java.util.Date` — **actual type:** `String`.
   
   ### Vertex/Edge example (问题点 / 边数据举例)
   
   ```javascript
   
   ```
   
   ### Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)
   
   ```javascript
   
   ```


-- 
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]

Reply via email to