Make SQL select more specific (#237)

[bbimber]

Related to: https://www.labkey.org/ONPRC/Support%20Tickets/issues-details.view?issueId=52640

[labkey-martyp]

Thanks Ben, looks good.

[bbimber]

@labkey-martyp, thoughts on handling this build failure? do i have the wrong base branch for what TeamCity needs or something like this?

Josh's change to AbstractDataDefinedTable should have been merged into this branch: https://github.com/LabKey/LabDevKitModules/blob/25.3_fb_sharedsql/LDK/api-src/org/labkey/api/ldk/table/AbstractDataDefinedTable.java

[labkey-martyp]

@labkey-martyp, thoughts on handling this build failure? do i have the wrong base branch for what TeamCity needs or something like this?

Josh's change to AbstractDataDefinedTable should have been merged into this branch: https://github.com/LabKey/LabDevKitModules/blob/25.3_fb_sharedsql/LDK/api-src/org/labkey/api/ldk/table/AbstractDataDefinedTable.java

Not sure what access you have on TC, there's not a build break on TC just a test failure. Looks like due to showing a date instead of the expected date time. Looping in @labkey-danield as it looks like he made the change.

java.lang.AssertionError: expected:<[Participant0001_gDNA, Participant0001, 2008-04-23 00:00, gDNA, , , Freezer1, , , , , , , , , , , , , , , , , , , , , , , , ]> but was:<[Participant0001_gDNA, Participant0001, 2008-04-23, gDNA, , , Freezer1, , , , , , , , , , , , , , , , , , , , , , , , ]>
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:120)
at org.junit.Assert.assertEquals(Assert.java:146)
at org.labkey.test.tests.external.labModules.LabModulesTest.samplesTableTest(LabModulesTest.java:1445)
at org.labkey.test.tests.external.labModules.LabModulesTest.testSteps(LabModulesTest.java:236)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.labkey.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:27)
at org.labkey.test.BaseWebDriverTest$6$1.evaluate(BaseWebDriverTest.java:858)
at org.labkey.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:27)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:833)

[bbimber]

I get the impression my view of TeamCity does differ from LK employees, but I see this build break: https://teamcity.labkey.org/buildConfiguration/LabKey_253Release_External_Discvr_BuildDiscvr/3450000

However, I see this issue does link to the test failure you point out. That test failure was fixed in the discvr-25.3 branch, which is ahead of the release-25.3-snapshot branch. In any case, given that result I think we can safely merge this PR.