Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-11-15

Channels

#xtdb
<
2022-11-15
>
sheluchin11:11:00

I'm getting this error when adding an :order-by clause to my query: 

=> ClassCastException
Execution error (ClassCastException) at java.time.Instant/compareTo (Instant.java:207).
class java.util.Date cannot be cast to class java.time.Instant (java.util.Date and java.time.Instant are in module java.base of loader 'bootstrap')
I have to do explicit conversion in my query to support this comparison?

refset11:11:09

Hi @UPWHQK562 yes it is the case currently that you would need to explicitly convert these types to match, using a function predicate, before order-by can sort correctly

zeitstein12:11:37

I faced the same problem recently. I adopted a strategy to only store Instants in DB. Not sure that was the correct call 🙂

sheluchin12:11:35

Thanks for the tips. I've been away from my XTDB project for a while and came back to find this bug when starting to get going again. Not sure where it came from, but guess for now I'll do the conversion. Probably the best solution would be to store a consistent data type.

licht1stein19:11:47

If I have a node config like this: {:xtdb.jdbc/connection-pool {:dialect {:xtdb/module 'xtdb.jdbc.psql/->dialect} :db-spec (:db-spec conf)} :xtdb/tx-log {:xtdb/module 'xtdb.jdbc/->tx-log :connection-pool :xtdb.jdbc/connection-pool} :xtdb/document-store {:xtdb/module 'xtdb.jdbc/->document-store :connection-pool :xtdb.jdbc/connection-pool} :xtdb/index-store {:kv-store {:xtdb/module `rocks/->kv-store, :db-dir (io/file (:db-dir conf) "index-store")}} :xtdb.lucene/lucene-store {:db-dir (io/file (:db-dir conf) "lucene-store")}} Is it correct that for another node on the same machine I need to change "index-store" to another directory? So each node needs to have a separate index-store, but I can keep other options the same? Is this the best way to set up a PostgreSQL back-end?

refset12:11:34

Hi @U01V67SBM55 sorry for the very late reply - you can certainly run multiple nodes on the same machine like this, but outside of testing or workload isolation I'm not sure why you would 🙂 > Is it correct that for another node on the same machine I need to change "index-store" to another directory? essentially yes, the state of the index-store is the node, there is no built-in concept like "unique node ID" so it all comes down to holding a lock on the underling KV store > Is this the best way to set up a PostgreSQL back-end? that looks right to me blob_thumbs_up