Open yanye666 opened 1 year ago
I hit the same issue in an ETL tool called Pentaho
Hi @yanye666, is this the issue we discussed on Telegram? You can update your query to use parseDateTimeBestEffort
or clean up values expression(e.g. insert into table values(?,now(),?)
-> insert into table(a,c) values(?,?)
), so that JDBC driver can infer table schema automatically.
-- DB::Exception: Cannot parse string '2023-02-02 18:26:21.363'
select '2023-02-02 18:26:21.363'::DateTime
-- returns 2023-02-02 18:26:21
select parseDateTimeBestEffort('2023-02-02 18:26:21.363')
I hit the same issue in an ETL tool called Pentaho
Can you customize insert query to use parseDateTimeBestEffort function as suggested above?
By the way, it's just my personal opinion, that Pentaho Kettle/Data Integration is a dying product, you'd better consider its successor Apache Hop.
Hi @yanye666, is this the issue we discussed on Telegram? You can update your query to use
parseDateTimeBestEffort
or clean up values expression(e.g.insert into table values(?,now(),?)
->insert into table(a,c) values(?,?)
), so that JDBC driver can infer table schema automatically.-- DB::Exception: Cannot parse string '2023-02-02 18:26:21.363' select '2023-02-02 18:26:21.363'::DateTime -- returns 2023-02-02 18:26:21 select parseDateTimeBestEffort('2023-02-02 18:26:21.363')
I just use insert into table(a,c) values(?,?)) introduction java.util.date Error occurred
Telegram, you won't reply to me
Can you customize insert query to use parseDateTimeBestEffort function as suggested above?
Nope, I have no control over the ETL code. It also failed on Data Value Lookup using PreparedStatement (workaround toString and create a view or ALIAS columns)
By the way, it's just my personal opinion, that Pentaho Kettle/Data Integration is a dying product, you'd better consider its successor Apache Hop.
100%, this is legacy code. Sending a java.util.Date to a Date field does not seem to be to crazy :-)
Can you customize insert query to use parseDateTimeBestEffort function as suggested above?
Nope, I have no control over the ETL code. It also failed on Data Value Lookup using PreparedStatement (workaround toString and create a view or ALIAS columns)
By the way, it's just my personal opinion, that Pentaho Kettle/Data Integration is a dying product, you'd better consider its successor Apache Hop.
100%, this is legacy code. Sending a It's crazy not to support java.util.Date It needs to be compatible with this type! to a Date field does not seem to be to crazy :-)
Not supporting java.util.Date is very violent, and this solution of invading SQL is not good.
Later, I will output an abnormal time type, which I have encountered in production, and I am very upset.
@zhicwu
Workaround: Try to adjust the clickhouse setting
date_time_input_format=best effort (instead of basic which is default)
解决方法:试调整 clickhouse 设置
date_time_input_format=best effort(而不是默认的基础)
lower version support. Do you need to adjust parameters for an advanced version? I don't think it's reasonable.
It also failed on Data Value Lookup using PreparedStatement (workaround toString and create a view or ALIAS columns)
That sounds really painful, any specific query you can share and I'll see if I can help.
Sending a java.util.Date to a Date field does not seem to be to crazy :-)
@aadant, hahaha, very true. The problem is on ClickHouse side. Since it does not support prepared statement like other databases, the JDBC driver has to figure out column types by itself. It either trusts the intention(in this case, java.util.Date is more suitable for DateTime64, not DateTime32 or Date), or try to infer parameter type by parsing the query(when input
function or a clean values
expression was used). Understood the query and parameters came from Kettle, but there's user defined Java/script step that you can leverage.
Not supporting java.util.Date is very violent, and this solution of invading SQL is not good. Later, I will output an abnormal time type, which I have encountered in production, and I am very upset.
@yanye666, calm down and don't be sad. Sorry I could not answer all questions in time, as I only work on this project in my spare time. As to the issue, as I explained in above, due to various limitation, you'd better take a workaround instead of counting on a feature being implemented soon.
Sure, feel free to share more cases and I'll try to help.
date_time_input_format=best effort (instead of basic which is default)
thanks, looks like a reasonable workaround (will set it on the user profile that is hit by the issue)
This is me testing the entry between two versions of different types. clickhouse version :22.1.3.7
notice:
Test | Remark | 0.3.1 | 0.3.2-11patch |
---|---|---|---|
testDefault | The test uses the database default | :white_check_mark: | :white_check_mark: |
testDefaultNull | Insert null to test the database default | :white_check_mark: | :x: java.sql.SQLException: Cannot set null to non-nullable column #2 [create_time DateTime] |
testString | Test insert string | :white_check_mark: | :white_check_mark: |
testTimeSecond | Test insert second | :white_check_mark: | :x: Time zone problem exists, org.junit.ComparisonFailure: Expected :2023-02-05 11:42:12 Actual :2023-02-05 19:42:12 |
testTimeStamp | Test insert {@link Timestamp} | :white_check_mark: | :white_check_mark: |
testDate | Test insert {@link Date} | :x: ru.yandex.clickhouse.except.ClickHouseException: ClickHouse exception, code: 6, host: 127.0.0.1, port: 8123; Code: 6. DB::Exception: Cannot parse string 'Sun Feb 05 19:51:12 CST 2023' as DateTime | :x: java.time.format.DateTimeParseException: Text 'Sun Feb 05 19:42:11 CST 2023' could not be parsed at index 0 |
testLocalDateTime | Test insert {@link LocalDateTime} | :white_check_mark: | :white_check_mark: |
testLocalDate | Test insert {@link LocalDate} | :white_check_mark: | :white_check_mark: |
There were other issues after the upgrade
in mybatis. mybatis has DateTypeHandler, which is implemented based on setTimeStamp, so java.util.Date is also supported in mybatis
According to the previous tests, mybatis should support insertion, but we have a special way to write it, as follows, which will cause an error.
Test | Remark | 0.3.1 | 0.3.2-11patch |
---|---|---|---|
testDateByMybatis | insert into test_date_time values(#{customerId},#{date}) | :white_check_mark: | :white_check_mark: |
insertDateBySelect | insert into test_date_time select #{customerId},#{date} | :white_check_mark: | :x: Cause: java.sql.BatchUpdateException: Code: 6. DB::Exception: Cannot parse string '2023-02-06 14:27:57.357' as DateTime: |
Thank you @yanye666 for summarizing issues you ran into and providing testing code. Apologize getting back a bit late as I'm still trying to fix an issue I encountered during benchmark over the weekend.
TabSeparated
to RowBinary
(not only for performance but also resolving serialization and deserialization issues along with better timezone support), and the latter does not support specifying null for a non-nullable column - null_as_default
option was added as a workaround for some but not all casesSince everyone else using mybatis will likely run into the same issues, are you willing to contribution a dialect or so to benefit more users?
Thanks Your summary and answer, My test is divided into two parts, the one above is jdbc mode, and the one below is mybatis mode.
on 0.3.1. Inserting clickhouse directly through mybatis has very low performance. So I used jdbc primordial(I don't know if there is any improvement after the upgrade.), which is why I am mainly testing jdbc mode.
Recently, I found your insert example. insert example
It seems that using jdbc is not the best way. Do you have a test report? If not, I will try to test it later.
I don't think the performance of using mybatis insert in 0.3.2 has improved either.
A little suggestion, for me, For the insert example, insert bitmap example. Maybe the example you wrote is not easy to find.😅 I hope to find them more easily.Very helpful
I don't know if there is any improvement after the upgrade.
In general, v0.3.2 is a few times faster than before due to improvements below:
1) data format changed from TabSeparated
to RowBinary
, meaning relatively less overhead in serialization, deserialization and transportation
2) more features like input function and async insert
3) configurable buffer and request chunk size for tweaking
To me, upgrading to v0.3.2 is mainly about stability (no more failed to respond
error) and sunset legacy driver as it's no longer maintained.
Do you have a test report?
I think I shared the link to you on Telegram. See #768 (by expanding 0.3.2). I have a few more test results generated in these days but it's for v0.4.1.
Maybe the example you wrote is not easy to find.😅 I hope to find them more easily.Very helpful
Yes, the documentation is awful here. Please feel free to send us pull requests by adding more examples and documents, thanks in advance!
version:
clickhouse:21.7 clickhouse-jdbc 0.3.2-patch11
issue:
Caused by: java.sql.BatchUpdateException: Code: 6, e.displayText() = DB::Exception: Cannot parse string '2023-02-02 18:26:21.363' as DateTime: syntax error at position 19 (parsed just '2023-02-02 18:26:21'): while converting source column
'2023-02-02 18:26:21.363'
to destination column task_date (version 21.3.4.25)java.util.Date ,This type of writing needs to be supported,in mybatis,Instead of using the special form ‘input’
related issues
863
upgrade 0.3.2-patch11