Title
#users-public
j

Jonas Degelo

11/17/2022, 2:17 PM
Hi there, I have an issue with a very specific table, it is just one column of timestamps. this column is also the dedicated "timestamp" column. It's created with the following SQL statement
CREATE TABLE ts(time_stamp TIMESTAMP) timestamp(time_stamp) PARTITION BY DAY;
I am using the questdb python library to insert data using the Influx DB line protocol. I have the following python code:
from datetime import datetime
from questdb.ingress import Buffer, Sender

user='admin'
password='quest'
host='localhost'
port=9009
database='qdb'

buf = Buffer()

ts_one = datetime.fromtimestamp(180)
ts_two = datetime.fromtimestamp(360)
print(ts_one)
print(ts_two)

buf.row('ts', symbols=None, columns= {'time_stamp': ts_one}, at=ts_two)
buf.row('ts_', symbols=None, columns= {'time_stamp': ts_one}, at=ts_two)
print(buf)

with Sender(host, port) as sender:
    sender.flush(buf)
the table
ts_
wasn't previously created. Now I'd expect to either have a timestamp at 3 or 6 minutes inside my
ts
table, but I end up with one at .18 seconds (
1970-01-01T00:00:00.180000Z
). In
ts_
on the other hand I get the expected value of 3 minutes in the
time_stamp
column and 6 minutes in a autogenerated column called
timestamp
. I get the correct value into
ts.time_stamp
if I multiply the integer used for creating the datetime by a factor 1000, but this feels hacky I have tried adding a row to the buffer with
columns=None
or
columns={}
with just
at=ts_one
but this didn't actually add a row to the buffer, I suppose because the row is in fact empty. If I omit the
at
parameter a new column will be created for the at value, and that's not what I want either. QuestDB version: 6.5.5 I've added screenshots for the values in the
ts
and
ts_
tables Any help is greatly appreciated, thank you
Andrey Pechkurov

Andrey Pechkurov

11/17/2022, 2:44 PM
Hello, This GH issue looks relevant:https://github.com/questdb/questdb/issues/2691 ATM we don't support columnless rows in ILP, i.e. rows with timestamp only, so you'd have to include an artificial column to your table (e.g. of BYTE type since it's the smallest one) to have ILP working as expected. In the meanwhile, could you write a message in the above GH issue describing your use case, so that we know that this feature is in demand?
j

Jonas Degelo

11/17/2022, 2:55 PM
Thank you! that is good to know. I will add a second column to my schema then