-
Notifications
You must be signed in to change notification settings - Fork 25.2k
SQL: test coverage for JdbcResultSet #32813
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
deb0b03
34bd90f
54834c9
7ce8fd8
9d802a9
906ca43
f14cb8a
493fc85
c32a997
24ec3bf
6325807
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -92,7 +92,7 @@ public void testThrownExceptionsWhenSettingStringValues() throws SQLException { | |
JdbcPreparedStatement jps = createJdbcPreparedStatement(); | ||
|
||
SQLException sqle = expectThrows(SQLException.class, () -> jps.setObject(1, "foo bar", Types.INTEGER)); | ||
assertEquals("Conversion from type [VARCHAR] to [Integer] not supported", sqle.getMessage()); | ||
assertEquals("Unable to convert value [foo bar] to an Integer", sqle.getMessage()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should probably be consistent in the messages. Half of the messages say "Unable to convert" another half "Conversion from type " I understand that in one case we bailout earlier by just looking at type, but in other case we are actually trying to parse the string. But I wonder if it would makes sense to have the same type of message and specify value and type in both cases. |
||
} | ||
|
||
public void testSettingByteTypeValues() throws SQLException { | ||
|
@@ -550,7 +550,8 @@ public void testThrownExceptionsWhenSettingByteArrayValues() throws SQLException | |
} | ||
|
||
private long randomMillisSinceEpoch() { | ||
return randomLongBetween(0, System.currentTimeMillis()); | ||
// random between Jan 1st, 1970 and Jan 1st, 2050 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mostly just curious: Why this end bound? Also, should we also be testing epochMillis that are before 1970-01-01 as well since they are perfectly valid? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I saw this one before in ResultSetBaseTestCase. Maybe it's time to move it to ESTestCase along with other There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @colings86 @imotov since the suggestion is to move this to ESTestCase base class (and be part of the test infra in ES), any good ideas for the interval start date? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure why There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 That sounds like a great idea. As long as we don't pass that to H2 we should be fine. |
||
return ESTestCase.randomLongBetween(0, 2524608000000L); | ||
} | ||
|
||
private JdbcPreparedStatement createJdbcPreparedStatement() throws SQLException { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
/* | ||
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
* or more contributor license agreements. Licensed under the Elastic License; | ||
* you may not use this file except in compliance with the Elastic License. | ||
*/ | ||
|
||
package org.elasticsearch.xpack.qa.sql.nosecurity; | ||
|
||
import org.elasticsearch.xpack.qa.sql.jdbc.ResultSetTestCase; | ||
|
||
public class JdbcResultSetIT extends ResultSetTestCase { | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you add a JavaDoc here that just describes why nothing needs to be added to this class, at first glance it looks quite strange to extends a test class and not add any test or override any methods. I'm sure there is a reason but its not obvious on first looking why doing this is right There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, that confuses people. The reasons for this is that we want to run the same tests in two or three very different integration clusters. We should probably update all tests like this with comments explaining it. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,31 @@ | ||
/* | ||
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
* or more contributor license agreements. Licensed under the Elastic License; | ||
* you may not use this file except in compliance with the Elastic License. | ||
*/ | ||
|
||
package org.elasticsearch.xpack.qa.sql.security; | ||
|
||
import org.elasticsearch.common.settings.Settings; | ||
import org.elasticsearch.xpack.qa.sql.jdbc.ResultSetTestCase; | ||
|
||
import java.util.Properties; | ||
|
||
public class JdbcResultSetIT extends ResultSetTestCase { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is enough different for this to be worth testing with security? |
||
@Override | ||
protected Settings restClientSettings() { | ||
return RestSqlIT.securitySettings(); | ||
} | ||
|
||
@Override | ||
protected String getProtocol() { | ||
return RestSqlIT.SSL_ENABLED ? "https" : "http"; | ||
} | ||
|
||
@Override | ||
protected Properties connectionProperties() { | ||
Properties sp = super.connectionProperties(); | ||
sp.putAll(JdbcSecurityIT.adminProperties()); | ||
return sp; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yikes