Should projected collections preserve temporal item types in the Java remote client? #4843

TobiasJoseHermann · 2026-06-30T14:10:18Z

TobiasJoseHermann
Jun 30, 2026

Hi ArcadeDB team,

I am migrating code from OrientDB to ArcadeDB and would like to clarify the expected responsibility around projected collections of temporal values in the Java remote client.

With arcadedb.dateTimeImplementation=java.time.LocalDateTime, scalar DATETIME projections are converted correctly to LocalDateTime, but DATETIME values nested inside a projected collection are returned as raw Long epoch-millis values.

Minimal example:

CREATE VERTEX TYPE Event IF NOT EXISTS;
CREATE PROPERTY Event.startedAt DATETIME IF NOT EXISTS;

CREATE VERTEX TYPE EventGroup IF NOT EXISTS;
CREATE EDGE TYPE EventGroup_events IF NOT EXISTS;

INSERT INTO EventGroup SET id = 'g1';
INSERT INTO Event SET id = 'e1', startedAt = '2026-01-02 03:04:05';

CREATE EDGE EventGroup_events
FROM (SELECT FROM EventGroup WHERE id = 'g1')
TO (SELECT FROM Event WHERE id = 'e1');

This scalar projection returns the configured Java temporal type:

try (ResultSet rs = db.query("sql",
    "SELECT startedAt FROM Event WHERE id = 'e1'")) {
  Object startedAt = rs.next().getProperty("startedAt");
  System.out.println(startedAt.getClass());
  // java.time.LocalDateTime
}

But this projected collection returns a List<Long>:

try (ResultSet rs = db.query("sql",
    "SELECT out('EventGroup_events').startedAt AS dates FROM EventGroup WHERE id = 'g1'")) {
  List<?> dates = rs.next().getProperty("dates");
  System.out.println(dates.get(0).getClass());
  // java.lang.Long
}

So the same schema-declared DATETIME property is converted when selected directly, but not when selected through a collection projection.

Questions:

Is this the expected behavior for remote query projections?
When a projected collection is produced from a schema-declared temporal property, is it viable for ArcadeDB to preserve or infer the item type?
```
SELECT out('EventGroup_events').startedAt AS dates FROM EventGroup
```
where Event.startedAt is declared as DATETIME.
Or should applications treat nested values inside projected collections as untyped remote values and convert them explicitly?

I am asking because a naive solution on the server side could require inspecting collection contents or adding nested type metadata to the remote JSON result, and I am not sure whether that tradeoff fits ArcadeDB's design.

Thanks.

lvca · 2026-06-30T14:30:48Z

lvca
Jun 30, 2026
Maintainer

Hi @TobiasJoseHermann, thanks for the very precise report - you've correctly identified the behavior, and your intuition about the design tradeoff is right.

Short answer: yes, this is currently expected (it's a limitation, not random), and no, the remote client cannot today infer the element type for a projected collection. Here's exactly why.

Why scalar works but the collection doesn't

Over the HTTP/remote protocol, each projection column carries a single type hint (the @props metadata) that the Java client uses to coerce the value back to a typed object.

For SELECT startedAt, the column value is a temporal, so the server tags the column as DATETIME and formats it as an ISO string. The remote client sees the DATETIME hint and rebuilds a LocalDateTime (honoring arcadeTimeImplementation).
For SELECT out('EventGroup_events').startedAt AS dates, the column value is a List, so the server can only tag the column as LIST. The hint mechanism is one type per column and has no slot for the element type. The individual DATETIME items are then written into the JSON array as raw epoch-millis numbers (arrays don't carry the date format that scalar columns do). On the client, there is simply no element-type information left to coerce against, so you get List<Long>.

So the type isn't being lost on the client; it never reaches the wire for collection elements in the first place. The alias dates is also not a schema property of EventGroup, so even the schema-driven path that handles declared LIST OF DATETIME properties can't kick in here.

Your three questions

Inconsistent and expected? Both, unfortunately. It's a known gap in the projection metadata, not intended divergent behavior.
Can it infer item types from schema? Not reliably. A projection like out(...).startedAt is computed; the result has no declared schema property to read an element type from, and a projected collection can legitimately be heterogeneous. We could infer it for the homogeneous case, but it requires a protocol change (carrying element-type metadata for collection columns and recursing during deserialization).
Should apps convert manually? For now, yes - that's the reliable workaround today.

Workaround

Since the values are epoch-millis Long, convert on the client:

List<Long> raw = result.getProperty("dates");
List<LocalDateTime> dates = raw.stream()
    .map(ms -> LocalDateTime.ofInstant(Instant.ofEpochMilli(ms), ZoneId.systemDefault()))
    .toList();

Alternatively, you can force the temporal into a stable string at query time, e.g. out('EventGroup_events').startedAt.format('yyyy-MM-dd HH:mm:ss') AS dates, and parse that - which avoids any ambiguity about whether the number is millis vs seconds.

Going forward

I think the cleanest fix is to make the server format collection temporal elements the same way scalar columns are (ISO strings honoring the schema precision) and/or emit an element-type hint so the client can coerce them. That gives an unambiguous, round-trippable payload without forcing apps to special-case it. If you'd like, open an issue and we'll track it - this is a reasonable thing to close.

Thanks again for the detailed write-up and for migrating from OrientDB. 🙏

0 replies

TobiasJoseHermann · 2026-07-01T10:55:17Z

TobiasJoseHermann
Jul 1, 2026
Author

Hi @lvca, thanks for the clear and detailed explanation!

I understand the protocol limitation. For now, I'll go with the query-side workaround by using .format() in the projection, and parsing the strings in Java. This guarantees zero ambiguity about the precision compared to raw millis.

As you suggested, I'll open an issue so this enhancement can be tracked for the future. Thanks again for the support!

1 reply

TobiasJoseHermann Jul 1, 2026
Author

I've reported the issue #4849

Navigation Menu

Repository navigation

Should projected collections preserve temporal item types in the Java remote client? #4843

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Should projected collections preserve temporal item types in the Java remote client? #4843

Uh oh!

TobiasJoseHermann Jun 30, 2026

Replies: 2 comments · 1 reply

Uh oh!

lvca Jun 30, 2026 Maintainer

Uh oh!

TobiasJoseHermann Jul 1, 2026 Author

Uh oh!

TobiasJoseHermann Jul 1, 2026 Author

TobiasJoseHermann
Jun 30, 2026

Replies: 2 comments 1 reply

lvca
Jun 30, 2026
Maintainer

TobiasJoseHermann
Jul 1, 2026
Author

TobiasJoseHermann Jul 1, 2026
Author