Hi, Kelvin It is not possible to use datetime() in bytecode. Now datetime()` is used as a marker that the next string should be treated as a DateTime, because there is no other way to pass a date in gremlin request.
One more option is to introduce new step to get some values during the script executing, for example supply(S.now) // current server date with possible extensions like supply(S.uuid) // server side uuid supply(S.int) // random integer supply(S.int, 10) // random integer between 0 and 10 like randomInt() supply(S.intCounter, 0) // an integer counter that increments from zero supply(S.serverVersion) // server version supply(S.requestQueueLength) // some server setting Regards, Valentyn On Wed, Sep 27, 2023 at 11:27 AM Kelvin Lawrence <gfx...@yahoo.com.invalid> wrote: > I much prefer having datetime() with no parameters return the current > server date/time. This also keeps the function similar in nature to other > query languages (e.g. Cypher). I have had several Gremlin users tell me > they were surprised when it did not already behave that way wen they tried > it as it seemed "obvious to them" that that is how it would work. > Cheers, Kelvin > On Tuesday, September 26, 2023 at 07:33:57 PM CDT, Valentyn Kahamlyk < > valent...@bitquilltech.com.invalid> wrote: > > Hi all, > > Currently, when using a gremlin, there is no way to use the current > server time in requests. This can be convenient for storing the > creation or update date of elements. Also may be useful when examining > query performance. > > I propose adding this feature. > > There are some ways to implement it > 1. Add a new step `currentDateTime()` which will return the current UTC > time. > pros: compatible with both bytecode and gremlin > cons: one more step > 2. Extend `inject` step to accept some kind of tokens, for example > `inject(DT.now)` or `inject(DT.utcnow)` > pros: can be reused existing step > cons: not feel like gremlin > 3. Extend `datetime()` function to return current time without arg. > pros: clean and easy to implement > cons: not compatible with bytecode, what I consider as a blocker > > I plan to implement option 1 if there are no objections. > > What do you think? > > Regards, Valentyn >
