Solved: Gremlin Python Exceptions with .property("timeStamp", 0)
The Issue:
In the Python code below:
def create_edge(self, from_v: Vertex, to_v: Vertex, edge_label: str, related_as: str,
updated_by_uuid: str = INebulaGraph.uuid_system) -> Edge:
uuid = DateAndUuidUtils.uuid_generate()
now = DateAndUuidUtils.datetime_of_now()
updated_on = DateAndUuidUtils.java_epoch_of(now)
updated_on_str = DateAndUuidUtils.datetime_to_iso(now)
created_edge: Edge = self.g.add_e(edge_label). \
from_(from_v).to(to_v). \
property("name", ""). \
property("updatedOn", updatedOn). \
property("updatedOnStr", updated_on_str). \
property("relatedAs", related_as). \
property("updatedBy", updated_by_uuid). \
property("uuid", uuid). \
next()
return created_edge
Where my DateAndUuidUtils.datetime_of_now() returns a python (int) of the Java Epoch value via datatime(). When above code is executed it exceptions by the underlying code saying that the value is too big and use gremlin bigint.
Solved:
Using statics.long() has fixed this issue.
from gremlin_python.statics import long
Change property("updatedOn", updatedOn) to property("updatedOn", long(updatedOn))
Additional Note:
* A double value goes in without any problem. It is only python int() into Gremlin.
* I would hope the error message can be a bit more friendly as to what I can do.
* The compare code in graphbinaryV1.py:dictify looks buggy, it's comparing the range much bigger than the long value.
if obj < -9223372036854775808 or obj > 9223372036854775807: obj is much smaller in my case than the range it compares.3 Replies
This is an issue that seems to come up quite often. Improvements here is definitely something we should target whether it be some sort of auto-casting or at least clearer exceptions.
The range in graphbinaryV1.py:dictify seems ok to me, those are the correct values for the java long type (it would be nice if the types could be decoupled somewhat from Java types but let's save that for a future discussion). It's not immediately obvious to me why you would get the
"Value too big, please use bigint Gremlin type" exception if your value is within the correct range.Just additional info on this. I push "updateOn" as Java epoc long value. The property set code stopped working at some point until 6/22/23 PDT so I would have to assume that the timestamp value much have just crossed some boundary.
The UTC epoch for 6/21/2023 was 1655769600000 and 6/22 as 1655856000000 and I can't see any drastic boundary. I tried to reproduce this but was unable to with tinkergraph. I will try the Janus next. But if I cannot reproduce it it would be hard to file a bug.
The UTC epoch for 6/21/2023 was 1655769600000 and 6/22 as 1655856000000 and I can't see any drastic boundary. I tried to reproduce this but was unable to with tinkergraph. I will try the Janus next. But if I cannot reproduce it it would be hard to file a bug.
from datetime import datetime
from random import random
from gremlin_python.process.anonymous_traversal import traversal
from gremlin_python.driver.driver_remote_connection import DriverRemoteConnection
from gremlin_python.process.graph_traversal import GraphTraversalSource
connection = DriverRemoteConnection("ws://localhost:8182/gremlin", 'g')
g: GraphTraversalSource = traversal().with_remote(connection)
overflow = "overflow"
g.V().hasLabel(overflow).drop().iterate()
g.addV(overflow).iterate()
for _ in range(10000):
ry = random() * 24 + 2000
rm = random() * 11 + 1
rd = random() * 27 + 1
rh = random() * 24
rmm = random() * 60
rs = random() * 60
try:
dt = datetime(int(ry), int(rm), int(rd), int(rh), int(rmm), int(rs))
ts1 = dt.timestamp()
i_ts1 = int(ts1)
g.V().hasLabel(overflow).property("timestamp", i_ts1).iterate()
i_ts2 = g.V().hasLabel(overflow).values("timestamp").next()
# print(f"{i_ts1} / {ts2}")
if i_ts1 != i_ts2:
raise Exception("Conversion failed.")
except:
print(dt)
connection.close()
Also checked if there is any difference between python version 3.8 and 3.11 and still unable to repro.
This is over the Janus DB container too.That's a bit odd, I would expect this to be the sort of error that is pretty reliable to reproduce. For now I would expect that using statics.long() everywhere will prevent these issues. We do have a pair of tickets to clean this up a bit. Unfortunately I doesn't look like it will be resolved before the next TinkerPop release, I hope we could solve it soon though.
https://issues.apache.org/jira/browse/TINKERPOP-2943
https://issues.apache.org/jira/browse/TINKERPOP-2363