Activity for dbUnit
-
Jeff Jensen modified ticket #443
Set oracle and postgresql drivers to <scope>provided</scope>
-
Set oracle and postgresql drivers to <scope>provided</scope>
-
Thank you for reporting and investigating. Fixed in 3.0.0.
-
java.lang.NoClassDefFoundError org/apache/commons/compress/utils/IOUtils
-
Thank you for reporting and investigating. I removed IOUtils usage to eliminate the problem. Fixed in 3.0.0.
-
Jeff Jensen committed [7020b2] on dbunit
B445 Fix NoClassDefFoundError for IOUtils
-
Jeff Jensen committed [b2360e] on dbunit
B443 pom: mark postgresql as provided scope
-
Jeff Jensen committed [640842] on dbunit
B443 pom: mark postgresql as provided scope
-
Implement #232
-
Merged. Thank you so much for your patience and diligence with your updates.
-
Your IDE formatting differs from dbUnit formatter so I tweaked a few files for that and also updated changes.xml. I squashed my changes into your commit. also updated commit message.
-
Jeff Jensen committed [f0ad98] on dbunit
F232 Add TableDecoratorDataSet, GeneratedColumnFilter
-
Great, thank you! https://gitlab.com/dbUnit/dbunit-extension/-/pipelines/1511180040
-
Jeff Jensen committed [d09a0e] on dbunit
fixup! F232 Add TableDecoratorDataSet, GeneratedColumnFilter
-
Rich DiCroce posted a comment on merge request #50
Fixed. That column has been in the JDBC spec since 4.1 but apparently some drivers still don't implement it. The tests are now all passing on my machine using the default HSQLDB profile.
-
Thank you for doing it again! Regretfully its build fails on tests both my local and dbUnit CI on "java.sql.SQLException: Column not found: 24". https://gitlab.com/dbUnit/dbunit-extension/-/jobs/8175569590 Does the build pass for you?
-
Jeff Jensen committed [b1ebad] on dbunit
fixup! F232 Add TableDecoratorDataSet, GeneratedColumnFilter
-
Jeff Jensen committed [449f2e] on dbunit
F232 Add TableDecoratorDataSet, GeneratedColumnFilter
-
Done.
-
Thank you Rich. We just merged the JUnit 5 updates to master. I did a quick rebase of your branch on that and stopped at compiler errors simply due to time. I can proceed with it in the near future but if you want it in the 3.0.0 release, please rebase yet one more should-be-last-time and should merge smoothly then.
-
Jeff Jensen committed [b2f45d] on dbunit
Update changes.xml and index.xml for 3.0.0 changes
-
Jeff Jensen committed [0be66f] on dbunit
Update changes.xml and index.xml for 3.0.0 changes
-
Make dbUnit compatible with JUnit 5
-
Jeff Jensen committed [ffecb7] on dbunit
F250 ValueComparers: add Null, NotNull constants
-
F222 Updates to make dbUnit JUnit 5 compatible
-
Thank you so much for this awesome MR! It represents a lot of work and patience on your part to update so much.
-
F222 Updates to make dbUnit JUnit 5 compatible
-
Jeff Jensen committed [65b8ba] on dbunit
pom.xml: Write derby.log to build output dir
-
Jeff Jensen committed [6fb4e4] on dbunit
antTestBuildFile.xml: Fix property typo
-
Jeff Jensen committed [63de1a] on dbunit
F222 Upgrade to JUnit 5
-
Jeff Jensen committed [37eb8b] on dbunit
fixup! F222 Upgrade to JUnit 5
-
Jeff Jensen committed [b045ac] on dbunit
fixup! F222 Upgrade to JUnit 5
-
Jeff/Edward: I've rebased this branch on top of latest master. Any chance one of you could review and merge it?
-
Jeff Jensen committed [3ee957] on dbunit
pom.xml: Write derby.log to build output dir
-
Jeff Jensen committed [e3d027] on dbunit
antTestBuildFile.xml: Fix property typo
-
Jeff Jensen committed [11e35e] on dbunit
F222 Upgrade to JUnit 5
-
Jeff Jensen committed [a1982c] on dbunit
fixup! F222 Upgrade to JUnit 5
-
Jeff Jensen committed [73b72d] on dbunit
fixup! F222 Upgrade to JUnit 5
-
Jeff Jensen committed [558bad] on dbunit
pom.xml: Write derby.log to build output dir
-
Jeff Jensen committed [19f567] on dbunit
antTestBuildFile.xml: Fix property typo
-
Jeff Jensen committed [eaa328] on dbunit
F222 Upgrade to JUnit 5
-
Jeff Jensen committed [51d98b] on dbunit
fixup! F222 Upgrade to JUnit 5
-
Ticket moved from /p/dbunit/bugs/450/ Can't be converted: _fixed_release: (not fixed) _milestone: v2.8.x
-
Bump postgresqldriver version to 42.3.10
-
Jeff Jensen committed [6d8311] on dbunit
pom.xml: Write derby.log to build output dir
-
Jeff Jensen committed [8ba8f4] on dbunit
antTestBuildFile.xml: Fix property typo
-
Jeff Jensen committed [7583b1] on dbunit
F222 Upgrade to JUnit 5
-
Jeff Jensen committed [2c1339] on dbunit
pom.xml: Write derby.log to build output dir
-
Jeff Jensen committed [bac35b] on dbunit
antTestBuildFile.xml: Fix property typo
-
Jeff Jensen committed [4e9223] on dbunit
F222 Upgrade to JUnit 5
-
Jeff Jensen committed [12a708] on dbunit
antTestBuildFile.xml: Fix property typo
-
Jeff Jensen committed [54bda9] on dbunit
F222 Upgrade to JUnit 5
-
Jeff Jensen committed [6b7fed] on dbunit
antTestBuildFile.xml: Fix property typo
-
Andrew Johnson committed [6900ca] on dbunit
Modernize
-
luis created ticket #450
Bump postgresqldriver version to 42.3.10
-
Modernize
-
fixup! F222 Upgrade to JUnit 5
-
fixup! F222 Upgrade to JUnit 5
-
fixup! F222 Upgrade to JUnit 5
-
fixup! F222 Upgrade to JUnit 5
-
Replace maven parent
-
Jyotman Singh posted a comment on ticket #449
Hi Jeff, apologies for the late reply. This will take significant effort as the tests will require a complete rewrite due to the return type of the method changing and will also need to find a way to test the setSqlValue() method since it'll contain some logic too because of the above suggested approach. I'll try to find some time to do this but can't promise a timeline right now. Will keep you updated though if/when I start working on this. Thanks for the help so far! Also fine if someone else wants...
-
Hi Jyotman, just checking in to see how it's going on this one? Any questions or issues I can help with?
-
Open to any other suggestions. None to suggest at the moment. Good approach is to "fix it with tests" first then we can refactor to improve, if possible and needed. Thank you for reporting and solving this problem!
-
Hi Jeff, Yes, I agree! I'm also not happy with the additional steps required in setSqlValue() but I can't return Timestamp from typeCast because it doesn't retain the expected dataset zone. I need to return the correct zone along with the Timestamp so that the statement.setTimestamp can receive the correct zone along with the Timestamp in the form of the Calendar instance. So I deemed ZonedDateTime as the correct choice which retains the datatime as well as the desired zone. I thought about returning...
-
Hi Jeff, Yes, I agree! I'm also not happy with the additional steps required in setSqlValue() but I can't return Timestamp from typeCast because it doesn't retain the expected dataset zone. I need to return the correct zone along with the Timestamp so that the statement.setTimestamp can receive the correct zone along with the Timestamp in the form of the Calendar instance. So I deemed ZonedDateTime as the correct choice which retains the datatime as well as the desired zone. I thought about returning...
-
Hi Jeff, Yes, I agree! I'm also not happy with the additional steps required in setSqlValue() but I can't return Timestamp from typeCast because it doesn't retain the expected dataset zone. I need to return the correct zone along with the Timestamp so that the setTimestamp can received the correct zone along with the Timestamp in the form of the Calendar instance. So I deemed ZonedDateTime as the correct choice which retains the datatime as well as the desired zone. I thought about returning a Calendar...
-
I see what you mean. Great analysis and writeup, thank you! The current return type java.sql.Timestamp uses the machine's default timezone which leads to neglecting the timezone provided in the DBUnit dataset. Hmmm that's unfortunate! Also I believe, fixing this would be considered a breaking change as people might be dependent on the existing behaviour? Possibly. It requires the differing zones, as in your case, so possibly less common(?). Also possibly avoided with a timestamp column defined with...
-
To make it more clear, I've added another test that would fail on any system not running on UTC - public void testWithTimezone_RetainTimezone() throws Exception { String ts = "2013-01-27 01:22:41.900 +0000"; String expected = "2013-01-27 01:22:41.9"; String received = THIS_TYPE.typeCast(ts).toString(); assertEquals(expected, received); } I've also attached a debug screenshot of my system running on UTC+8 (Singapore) timezone.
-
Hi Jeff, thanks for your prompt reply. This is difficult to test typeCast as the problem seems to be in the return type of the function itself. The current return type java.sql.Timestamp uses the machine's default timezone which leads to neglecting the timezone provided in the DBUnit dataset. To fix this would involve returning different type from typeCast that can respect the timezone provided in the dataset. But still to prove my point, this test would always fail. Same UTC value but depends on...
-
Hi Jeff, thanks for your prompt reply. This is difficult to test typeCast as the problem seems to be in the return type of the function itself. The current return type java.sql.Timestamp uses the machine's default timezone which leads to neglecting the timezone provided in the DBUnit dataset. To fix this would involve returning different type from typeCast that can respect the timezone provided in the dataset. But still to prove my point, currently this test would fail. Same UTC value but assume...
-
Hi Jeff, thanks for your prompt reply. This is difficult to test typeCast as the problem seems to be in the return type of the function itself. The current return type java.sql.Timestamp uses the machine's default timezone which leads to neglecting the timezone provided in the DBUnit dataset. To fix this would involve returning different type from typeCast that can respect the timezone provided in the dataset. But still to prove my point, currently this test would fail - public void test() throws...
-
Hi Jeff, thanks for your prompt reply. This is difficult to test typeCast as the problem seems to be in the return type of the function itself. The current return type java.sql.Timestamp uses the machine's default timezone which leads to neglecting the timezone provided in the DBUnit dataset. To fix this would involve returning different type from typeCast that can respect the timezone provided in the dataset. But still to prove my point, currently this test would fail - public void test() throws...
-
Hi Jeff, thanks for your prompt reply. This is difficult to test right the current function typeCast as the problem seems to be in the return type of the function itself. The current return type java.sql.Timestamp uses the machine's default timezone which leads to neglecting the timezone provided in the DBUnit dataset. To fix this would involve returning a type from typeCast that can respect the timezone provided in the dataset. But still to prove my point, this test fails - public void test() throws...
-
UTC Timestamp in dataset converted to local timezone in DB
-
Hi Jyotman, thank you for reporting the issue and digging into it. From your initial investigation work and description, it seems like a bug. Next step is to assess it further and if is a bug, reproduce it in tests and then fix. Have you reviewed the TimestampDataTypeTest class to see if it covers your scenario(s)? If it doesn't, can you add your scenarios/tests to it, adjust TimestampDataType to make the tests pass, and create a MR? I can review it, merge it, and publish a point release if you can...
-
UTC Timestamp in dataset converted to local timezone in DB
-
Edward Mann created merge request #57 on dbunit
F222 Dbunit5 fixed release
-
Fixed commits for junit 5 update
-
Yes, that is the correct branch.
-
Jeff Jensen committed [8b36b7] on dbunit
F222 Update to JUnit 5
-
Rich, i am looking over the existing merge requests wanting to get them caught up before i update to java 17+. I found your branch "computed-columns", i hope this is the correct one. If not can you send me a link to it? I will pull it and work on tests that are failing. We will most likely need to create a new merge request from that branch. Thanks
-
Junit 5 update
-
Rejecting this one as i opened another merge request.
-
Fixed commits for junit 5 update
-
Yes, they are there now, thanks.
-
Yes, they are there now, thanks.
-
I did, and i just did another merge from dbunit repo, only diff is the pom.xml with versions i updated. Is there a specific file that is diff i can use to figure out what's going on?
-
Great Ed! I noticed it's missing the 2.8.0 release and additional commits tho, prob need to fetch from dbunit's repo before the rebase.
-
@jeffjensen This is the merged commit for all my changes. I did merge with master before i pushed this. You know you're free to tell me to fix things if i did it wrong. Thanks
-
Jeff Jensen committed [d13768] on dbunit
Update Eclipse launchers
-
Jeff Jensen committed [76f093] on dbunit
Bump japicmp-maven-plugin version, enable report
-
dbUnit 2.8.0 Released
-
Jeff Jensen committed [97e84f] on dbunit
Prep for next release development
-
Jeff Jensen committed [522960] on dbunit
Bump site plugin and wagon-ssh versions
-
Jeff Jensen committed [e22289] on dbunit
Prep release 2.8.0
-
Add support for Yaml dataset format
-
I changed final SAXParser saxParser = SAXParserFactory.newInstance().newSAXParser(); To final SAXParser saxParser = SAXParserFactory.newInstance("com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl", null).newSAXParser(); That resolved the failure. So went to final SAXParser saxParser = SAXParserFactory.newDefaultInstance().newSAXParser(); and it looks good now.
-
I changed final SAXParser saxParser = SAXParserFactory.newInstance().newSAXParser(); To final SAXParser saxParser = SAXParserFactory.newInstance("com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl", null).newSAXParser(); That resolved the failure.
-
Update: Mysql and mssql2019 i was able to get to run and pass. oracle-* it has a dependency on com.oracle.database.xml:xdb. When i run tests i am having issues with that dependency being used for xml parsing. mvn -Pit-config,oracle10-ojdbc8 clean test verify -Dit.test="FlatDtdDataSetIT ERROR] Tests run: 16, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.605 s <<< FAILURE! -- in org.dbunit.dataset.xml.FlatDtdDataSetIT [ERROR] org.dbunit.dataset.xml.FlatDtdDataSetIT.testCreateDuplicateDataSet...
1 >