Menu
▾
▴
dbunit-developer
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(21) |
Jun
(56) |
Jul
(6) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(10) |
Mar
(11) |
Apr
(8) |
May
(4) |
Jun
(10) |
Jul
(15) |
Aug
(5) |
Sep
(2) |
Oct
(12) |
Nov
|
Dec
|
| 2004 |
Jan
(18) |
Feb
(33) |
Mar
(7) |
Apr
(3) |
May
(3) |
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(17) |
Oct
(17) |
Nov
(6) |
Dec
(1) |
| 2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
(8) |
May
(4) |
Jun
(2) |
Jul
|
Aug
(15) |
Sep
(5) |
Oct
(11) |
Nov
(5) |
Dec
|
| 2006 |
Jan
(10) |
Feb
(4) |
Mar
|
Apr
(3) |
May
(13) |
Jun
(1) |
Jul
(1) |
Aug
(9) |
Sep
(1) |
Oct
(1) |
Nov
(4) |
Dec
(32) |
| 2007 |
Jan
(15) |
Feb
(10) |
Mar
(9) |
Apr
(4) |
May
(9) |
Jun
(8) |
Jul
(8) |
Aug
(4) |
Sep
(43) |
Oct
(12) |
Nov
(8) |
Dec
(11) |
| 2008 |
Jan
(7) |
Feb
(52) |
Mar
(92) |
Apr
(19) |
May
(101) |
Jun
(212) |
Jul
(136) |
Aug
(102) |
Sep
(53) |
Oct
(58) |
Nov
(115) |
Dec
(122) |
| 2009 |
Jan
(58) |
Feb
(66) |
Mar
(82) |
Apr
(29) |
May
(27) |
Jun
(13) |
Jul
(27) |
Aug
(59) |
Sep
(104) |
Oct
(111) |
Nov
(77) |
Dec
(31) |
| 2010 |
Jan
(79) |
Feb
(52) |
Mar
(18) |
Apr
(19) |
May
(18) |
Jun
(10) |
Jul
(7) |
Aug
(45) |
Sep
(50) |
Oct
(36) |
Nov
(11) |
Dec
(36) |
| 2011 |
Jan
(10) |
Feb
(26) |
Mar
(11) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(8) |
Aug
(6) |
Sep
(6) |
Oct
(5) |
Nov
(2) |
Dec
(5) |
| 2012 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(16) |
Jul
(10) |
Aug
(1) |
Sep
(17) |
Oct
(22) |
Nov
(2) |
Dec
(5) |
| 2013 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(5) |
Dec
(3) |
| 2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(16) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(11) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(4) |
| 2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael M. <mic...@gm...> - 2012-06-19 14:12:33
|
Sorry for the late reply. I should have some time this weekend to follow up with some tests and a patch. Regards, Michael On Thu, Jun 14, 2012 at 12:19 AM, Jeff Jensen <jj...@ap...> wrote: > It's interesting you bring this up. I cannot remember the decision at the > time of writing; my only thought is it was an oversight. > > All the dbUnit tests I have written or have taught others to write using > this method are all absolute paths (start with /). Therefore the suggested > change would have no impact for my work, and I imagine most others', as the > default package is the dbUnit one, not one from the app class under test. > > Do you have a moment to write a couple more tests for the suggested change > (to demonstrate it's the desired behavior) and make a patch? > > > On Sat, Jun 9, 2012 at 6:50 PM, Michael Mercurio <mic...@gm...> > wrote: >> >> Hello John, >> >> Thanks for the quick response. >> >> I think the main advantage is that the file would be looked up in the >> classpath without needing to explicitly prefix the filename with '/'. >> When reading the documentation it's not really clear whether the >> filename is looked up using the absolute path or not. I had to look >> at the source code in order to tell what was happening. >> >> It is true that with the proposed change there is a slight loss in >> flexibility -- you loose the ability to specify pathnames relative to >> the current class. However, in virtually all cases (with the >> exception of a user extending AbstractDataFileLoader in their own >> class), the "current class" will be under org.dbunit.util. This >> doesn't seem very intuitive or useful to me. >> >> Because of this, in my own testing I've forgone using the load method >> and instead load a data set like this: >> >> URL url = this.getClass().getClassLoader().getResource(filename); >> IDataSet dataSet = new FlatXmlDataSetBuilder().build(url); >> >> Which is what I was hoping I could do with a single call without >> having to lookup the resource myself: >> IDataSet dataSet = new FlatXmlDataFileLoader().load(filename); >> >> The primary reason for my question was to understand the reasoning for >> the current implementation. Perhaps I'm missing something or maybe >> the current implementation is more inline with other APIs. >> >> Regards, >> Michael >> >> >> On Sat, Jun 9, 2012 at 6:16 PM, John Hurst <joh...@gm...> wrote: >> > Michael, >> > >> > I think your understanding is correct, so it seems to me that this >> > method is >> > intended to be used with fully-qualified resource paths beginning with >> > "/". >> > >> > What would be the advantage of your change? You would still need to give >> > a >> > fully-qualified path to a resource, right? Any other difference? >> > >> > John Hurst >> > >> > On Sun, Jun 10, 2012 at 8:13 AM, Michael Mercurio >> > <mic...@gm...> >> > wrote: >> >> >> >> Hello all, >> >> >> >> I'm wondering if there is an issue with >> >> AbstractDataFileLoader.load(String filename) in how it loads files >> >> from the classpath. >> >> >> >> The URL for the file is obtained on line 106 of >> >> AbstractDataFileLoader.java like this: >> >> >> >> URL url = this.getClass().getResource(filename); >> >> >> >> >From my understanding of java.lang.Class.getResource(String), unless >> >> prefixed with '/', the filename is required to be a relative pathname >> >> of the class (under org.dbunit.util.fileloader in this case). >> >> >> >> >From a user perspective, wouldn't it make sense to use the ClassLoader >> >> instead of the Class? Unless users are extending >> >> AbstractDataFileLoader in their own classes, their files are not >> >> likely to be located relative to current class (for DbUnit >> >> implementations, under org.dbunit.util.fileloader). >> >> >> >> I'm wondering if line 106 of AbstractDataFileLoader.java should be >> >> modified to: >> >> >> >> URL url = this.getClass().getClassLoader().getResource(filename); >> >> >> >> If not, would someone kindly explain the reasoning for the current >> >> method? >> >> >> >> Best regards, >> >> Michael >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Live Security Virtual Conference >> >> Exclusive live event will cover all the ways today's security and >> >> threat landscape has changed and how IT managers can respond. >> >> Discussions >> >> will include endpoint security, mobile security and the latest in >> >> malware >> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> _______________________________________________ >> >> dbunit-developer mailing list >> >> dbu...@li... >> >> https://lists.sourceforge.net/lists/listinfo/dbunit-developer >> > >> > >> > >> > >> > -- >> > Life is interfering with my game >> > >> > >> > ------------------------------------------------------------------------------ >> > Live Security Virtual Conference >> > Exclusive live event will cover all the ways today's security and >> > threat landscape has changed and how IT managers can respond. >> > Discussions >> > will include endpoint security, mobile security and the latest in >> > malware >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> > _______________________________________________ >> > dbunit-developer mailing list >> > dbu...@li... >> > https://lists.sourceforge.net/lists/listinfo/dbunit-developer >> > >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> dbunit-developer mailing list >> dbu...@li... >> https://lists.sourceforge.net/lists/listinfo/dbunit-developer > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > dbunit-developer mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbunit-developer > |
|
From: Jeff J. <jj...@ap...> - 2012-06-14 04:20:18
|
It's interesting you bring this up. I cannot remember the decision at the time of writing; my only thought is it was an oversight. All the dbUnit tests I have written or have taught others to write using this method are all absolute paths (start with /). Therefore the suggested change would have no impact for my work, and I imagine most others', as the default package is the dbUnit one, not one from the app class under test. Do you have a moment to write a couple more tests for the suggested change (to demonstrate it's the desired behavior) and make a patch? On Sat, Jun 9, 2012 at 6:50 PM, Michael Mercurio <mic...@gm...>wrote: > Hello John, > > Thanks for the quick response. > > I think the main advantage is that the file would be looked up in the > classpath without needing to explicitly prefix the filename with '/'. > When reading the documentation it's not really clear whether the > filename is looked up using the absolute path or not. I had to look > at the source code in order to tell what was happening. > > It is true that with the proposed change there is a slight loss in > flexibility -- you loose the ability to specify pathnames relative to > the current class. However, in virtually all cases (with the > exception of a user extending AbstractDataFileLoader in their own > class), the "current class" will be under org.dbunit.util. This > doesn't seem very intuitive or useful to me. > > Because of this, in my own testing I've forgone using the load method > and instead load a data set like this: > > URL url = this.getClass().getClassLoader().getResource(filename); > IDataSet dataSet = new FlatXmlDataSetBuilder().build(url); > > Which is what I was hoping I could do with a single call without > having to lookup the resource myself: > IDataSet dataSet = new FlatXmlDataFileLoader().load(filename); > > The primary reason for my question was to understand the reasoning for > the current implementation. Perhaps I'm missing something or maybe > the current implementation is more inline with other APIs. > > Regards, > Michael > > > On Sat, Jun 9, 2012 at 6:16 PM, John Hurst <joh...@gm...> wrote: > > Michael, > > > > I think your understanding is correct, so it seems to me that this > method is > > intended to be used with fully-qualified resource paths beginning with > "/". > > > > What would be the advantage of your change? You would still need to give > a > > fully-qualified path to a resource, right? Any other difference? > > > > John Hurst > > > > On Sun, Jun 10, 2012 at 8:13 AM, Michael Mercurio < > mic...@gm...> > > wrote: > >> > >> Hello all, > >> > >> I'm wondering if there is an issue with > >> AbstractDataFileLoader.load(String filename) in how it loads files > >> from the classpath. > >> > >> The URL for the file is obtained on line 106 of > >> AbstractDataFileLoader.java like this: > >> > >> URL url = this.getClass().getResource(filename); > >> > >> >From my understanding of java.lang.Class.getResource(String), unless > >> prefixed with '/', the filename is required to be a relative pathname > >> of the class (under org.dbunit.util.fileloader in this case). > >> > >> >From a user perspective, wouldn't it make sense to use the ClassLoader > >> instead of the Class? Unless users are extending > >> AbstractDataFileLoader in their own classes, their files are not > >> likely to be located relative to current class (for DbUnit > >> implementations, under org.dbunit.util.fileloader). > >> > >> I'm wondering if line 106 of AbstractDataFileLoader.java should be > >> modified to: > >> > >> URL url = this.getClass().getClassLoader().getResource(filename); > >> > >> If not, would someone kindly explain the reasoning for the current > method? > >> > >> Best regards, > >> Michael > >> > >> > >> > ------------------------------------------------------------------------------ > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. > Discussions > >> will include endpoint security, mobile security and the latest in > malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> _______________________________________________ > >> dbunit-developer mailing list > >> dbu...@li... > >> https://lists.sourceforge.net/lists/listinfo/dbunit-developer > > > > > > > > > > -- > > Life is interfering with my game > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > dbunit-developer mailing list > > dbu...@li... > > https://lists.sourceforge.net/lists/listinfo/dbunit-developer > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > dbunit-developer mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbunit-developer > |
|
From: John H. <joh...@gm...> - 2012-06-11 20:14:05
|
Michael, I agree with you. I guess we should change it unless anyone else thinks differently. John Hurst On Sun, Jun 10, 2012 at 11:50 AM, Michael Mercurio <mic...@gm... > wrote: > Hello John, > > Thanks for the quick response. > > I think the main advantage is that the file would be looked up in the > classpath without needing to explicitly prefix the filename with '/'. > When reading the documentation it's not really clear whether the > filename is looked up using the absolute path or not. I had to look > at the source code in order to tell what was happening. > > It is true that with the proposed change there is a slight loss in > flexibility -- you loose the ability to specify pathnames relative to > the current class. However, in virtually all cases (with the > exception of a user extending AbstractDataFileLoader in their own > class), the "current class" will be under org.dbunit.util. This > doesn't seem very intuitive or useful to me. > > Because of this, in my own testing I've forgone using the load method > and instead load a data set like this: > > URL url = this.getClass().getClassLoader().getResource(filename); > IDataSet dataSet = new FlatXmlDataSetBuilder().build(url); > > Which is what I was hoping I could do with a single call without > having to lookup the resource myself: > IDataSet dataSet = new FlatXmlDataFileLoader().load(filename); > > The primary reason for my question was to understand the reasoning for > the current implementation. Perhaps I'm missing something or maybe > the current implementation is more inline with other APIs. > > Regards, > Michael > > > On Sat, Jun 9, 2012 at 6:16 PM, John Hurst <joh...@gm...> wrote: > > Michael, > > > > I think your understanding is correct, so it seems to me that this > method is > > intended to be used with fully-qualified resource paths beginning with > "/". > > > > What would be the advantage of your change? You would still need to give > a > > fully-qualified path to a resource, right? Any other difference? > > > > John Hurst > > > > On Sun, Jun 10, 2012 at 8:13 AM, Michael Mercurio < > mic...@gm...> > > wrote: > >> > >> Hello all, > >> > >> I'm wondering if there is an issue with > >> AbstractDataFileLoader.load(String filename) in how it loads files > >> from the classpath. > >> > >> The URL for the file is obtained on line 106 of > >> AbstractDataFileLoader.java like this: > >> > >> URL url = this.getClass().getResource(filename); > >> > >> >From my understanding of java.lang.Class.getResource(String), unless > >> prefixed with '/', the filename is required to be a relative pathname > >> of the class (under org.dbunit.util.fileloader in this case). > >> > >> >From a user perspective, wouldn't it make sense to use the ClassLoader > >> instead of the Class? Unless users are extending > >> AbstractDataFileLoader in their own classes, their files are not > >> likely to be located relative to current class (for DbUnit > >> implementations, under org.dbunit.util.fileloader). > >> > >> I'm wondering if line 106 of AbstractDataFileLoader.java should be > >> modified to: > >> > >> URL url = this.getClass().getClassLoader().getResource(filename); > >> > >> If not, would someone kindly explain the reasoning for the current > method? > >> > >> Best regards, > >> Michael > >> > >> > >> > ------------------------------------------------------------------------------ > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. > Discussions > >> will include endpoint security, mobile security and the latest in > malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> _______________________________________________ > >> dbunit-developer mailing list > >> dbu...@li... > >> https://lists.sourceforge.net/lists/listinfo/dbunit-developer > > > > > > > > > > -- > > Life is interfering with my game > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > dbunit-developer mailing list > > dbu...@li... > > https://lists.sourceforge.net/lists/listinfo/dbunit-developer > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > dbunit-developer mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbunit-developer > -- Life is interfering with my game |
|
From: Michael M. <mic...@gm...> - 2012-06-09 23:50:25
|
Hello John,
Thanks for the quick response.
I think the main advantage is that the file would be looked up in the
classpath without needing to explicitly prefix the filename with '/'.
When reading the documentation it's not really clear whether the
filename is looked up using the absolute path or not. I had to look
at the source code in order to tell what was happening.
It is true that with the proposed change there is a slight loss in
flexibility -- you loose the ability to specify pathnames relative to
the current class. However, in virtually all cases (with the
exception of a user extending AbstractDataFileLoader in their own
class), the "current class" will be under org.dbunit.util. This
doesn't seem very intuitive or useful to me.
Because of this, in my own testing I've forgone using the load method
and instead load a data set like this:
URL url = this.getClass().getClassLoader().getResource(filename);
IDataSet dataSet = new FlatXmlDataSetBuilder().build(url);
Which is what I was hoping I could do with a single call without
having to lookup the resource myself:
IDataSet dataSet = new FlatXmlDataFileLoader().load(filename);
The primary reason for my question was to understand the reasoning for
the current implementation. Perhaps I'm missing something or maybe
the current implementation is more inline with other APIs.
Regards,
Michael
On Sat, Jun 9, 2012 at 6:16 PM, John Hurst <joh...@gm...> wrote:
> Michael,
>
> I think your understanding is correct, so it seems to me that this method is
> intended to be used with fully-qualified resource paths beginning with "/".
>
> What would be the advantage of your change? You would still need to give a
> fully-qualified path to a resource, right? Any other difference?
>
> John Hurst
>
> On Sun, Jun 10, 2012 at 8:13 AM, Michael Mercurio <mic...@gm...>
> wrote:
>>
>> Hello all,
>>
>> I'm wondering if there is an issue with
>> AbstractDataFileLoader.load(String filename) in how it loads files
>> from the classpath.
>>
>> The URL for the file is obtained on line 106 of
>> AbstractDataFileLoader.java like this:
>>
>> URL url = this.getClass().getResource(filename);
>>
>> >From my understanding of java.lang.Class.getResource(String), unless
>> prefixed with '/', the filename is required to be a relative pathname
>> of the class (under org.dbunit.util.fileloader in this case).
>>
>> >From a user perspective, wouldn't it make sense to use the ClassLoader
>> instead of the Class? Unless users are extending
>> AbstractDataFileLoader in their own classes, their files are not
>> likely to be located relative to current class (for DbUnit
>> implementations, under org.dbunit.util.fileloader).
>>
>> I'm wondering if line 106 of AbstractDataFileLoader.java should be
>> modified to:
>>
>> URL url = this.getClass().getClassLoader().getResource(filename);
>>
>> If not, would someone kindly explain the reasoning for the current method?
>>
>> Best regards,
>> Michael
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> dbunit-developer mailing list
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>
>
>
> --
> Life is interfering with my game
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
|
|
From: John H. <joh...@gm...> - 2012-06-09 22:16:23
|
Michael, I think your understanding is correct, so it seems to me that this method is intended to be used with fully-qualified resource paths beginning with "/". What would be the advantage of your change? You would still need to give a fully-qualified path to a resource, right? Any other difference? John Hurst On Sun, Jun 10, 2012 at 8:13 AM, Michael Mercurio <mic...@gm...>wrote: > Hello all, > > I'm wondering if there is an issue with > AbstractDataFileLoader.load(String filename) in how it loads files > from the classpath. > > The URL for the file is obtained on line 106 of > AbstractDataFileLoader.java like this: > > URL url = this.getClass().getResource(filename); > > >From my understanding of java.lang.Class.getResource(String), unless > prefixed with '/', the filename is required to be a relative pathname > of the class (under org.dbunit.util.fileloader in this case). > > >From a user perspective, wouldn't it make sense to use the ClassLoader > instead of the Class? Unless users are extending > AbstractDataFileLoader in their own classes, their files are not > likely to be located relative to current class (for DbUnit > implementations, under org.dbunit.util.fileloader). > > I'm wondering if line 106 of AbstractDataFileLoader.java should be > modified to: > > URL url = this.getClass().getClassLoader().getResource(filename); > > If not, would someone kindly explain the reasoning for the current method? > > Best regards, > Michael > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > dbunit-developer mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbunit-developer > -- Life is interfering with my game |
|
From: Michael M. <mic...@gm...> - 2012-06-09 20:14:05
|
Hello all, I'm wondering if there is an issue with AbstractDataFileLoader.load(String filename) in how it loads files from the classpath. The URL for the file is obtained on line 106 of AbstractDataFileLoader.java like this: URL url = this.getClass().getResource(filename); >From my understanding of java.lang.Class.getResource(String), unless prefixed with '/', the filename is required to be a relative pathname of the class (under org.dbunit.util.fileloader in this case). >From a user perspective, wouldn't it make sense to use the ClassLoader instead of the Class? Unless users are extending AbstractDataFileLoader in their own classes, their files are not likely to be located relative to current class (for DbUnit implementations, under org.dbunit.util.fileloader). I'm wondering if line 106 of AbstractDataFileLoader.java should be modified to: URL url = this.getClass().getClassLoader().getResource(filename); If not, would someone kindly explain the reasoning for the current method? Best regards, Michael |
|
From: SourceForge.net <no...@so...> - 2012-06-05 11:26:14
|
Bugs item #3532112, was opened at 2012-06-05 04:26 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3532112&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: matthias g (gommma) Summary: DB2 V9.7 Unable to load data with generated always column Initial Comment: I can't load a dataset into database when I have a generated always column in DB2 V9.7. Tried removing the column from the dataset and/or from the dtd file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3532112&group_id=47439 |
|
From: Jeff J. <jj...@ap...> - 2012-06-04 17:14:05
|
Hi, Create a Tracker item and attach a patch. If the code change has high test coverage, easy to apply (e.g. do not reformat files), and causes no other problems that I can detect, I will commit the change. Yes, a release is long overdue... On Fri, Jun 1, 2012 at 4:11 PM, Shijun Kong <sk...@in...>wrote: > Hi, > > I recently ran into an issue that DbUnit does not support PostgreSQL's > hstore data type. I have it fixed by extending PostgresqlDataTypeFactory > and creating a new HStoreType extends AbstractDataType. I'd like to know > how could I contribute it back to DbUnit. From website, the latest release > is in 2010. Not sure if this project is still active or not. > > -Shijun > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > dbunit-developer mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbunit-developer > > |
|
From: Shijun K. <sk...@in...> - 2012-06-01 21:38:31
|
Hi, I recently ran into an issue that DbUnit does not support PostgreSQL's hstore data type. I have it fixed by extending PostgresqlDataTypeFactory and creating a new HStoreType extends AbstractDataType. I'd like to know how could I contribute it back to DbUnit. From website, the latest release is in 2010. Not sure if this project is still active or not. -Shijun |
|
From: SourceForge.net <no...@so...> - 2012-04-15 16:17:31
|
Bugs item #3479543, was opened at 2012-01-25 02:17 Message generated for change (Comment added) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3479543&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Tobias Buchloh (tbuchloh) Assigned to: Jeff Jensen (jeffjensen) Summary: TimestampDataType cannot typeCast correct Timestamp strings Initial Comment: = Problem = We want to migrate dbunit from v2.2 to v2.4.8 and are now faced with the problem that some of our test cases do not work anymore due to changes in org.dbunit.dataset.datatype.TimestampDataType.typeCast(Object). In v2.2 the string "2010-05-19 08:38:45.123456" was converted into a correct java.sql.Timestamp-object. With v2.4.8 it will be converted silently to "2010-05-19 08:40:48.456" which is definitely not what we expected. = Possible cause = Looking in the code we found a problem beginning on line 91: <snip> try { // SimpleDateFormat uses millisecond precision only DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS"); Date date = df.parse(stringValue); return new java.sql.Timestamp(date.getTime()); } catch (ParseException e) { if (i < patterns.length) continue; throw new TypeCastException(value, this, e); } </snap> Using SimpleDateFormat for a nano precision type does not work, because it creates a java.util.Date-object which does not work with nanoseconds. In v2.2 the method Timestamp.valueOf(String) has been used. ---------------------------------------------------------------------- >Comment By: Jeff Jensen (jeffjensen) Date: 2012-04-15 09:17 Message: Duplicate of 3071408. (Thanks chrisphe) ---------------------------------------------------------------------- Comment By: Chris Pheby (chrisphe) Date: 2012-01-25 05:41 Message: This bug is the same as [3452801] TimestampDataType cannot parse java.sql.Timestamp.toString [3071408] New Handling of Timestamp in 2.4.8 has error with subseconds I already submitted a patch for this ((the patch was applied to trunk in February last year) - See the issue at https://sourceforge.net/tracker/?func=detail&aid=3071408&group_id=47439&atid=449491 This bug makes 2.4.8 unusable for anyone working with timestamps, is there any chance a 2.4.9 release can be made from the trunk after this patch was applied ? Thanks Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3479543&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-04-15 16:13:01
|
Bugs item #3452801, was opened at 2011-12-06 13:11 Message generated for change (Comment added) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3452801&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Ken Huffman (kenhuffman) Assigned to: matthias g (gommma) Summary: TimestampDataType cannot parse java.sql.Timestamp.toString Initial Comment: java.sql.Timestamp.toString() will trim trailing zeros with fractional seconds. E.g. 780 milliseconds is written "12:34:56.78" instead of "12:34:56.780" Unfortunately TimestampDataType.typeCast() parses "12:34:56.78" incorrectly as 78 milliseconds (i.e. "12:34:56.078") instead of the correct 780 milliseconds. This causes FlatXmlDatSetBuilder to incorrectly interpret files written by FlatXmlWriter when they contain timestamps. ---------------------------------------------------------------------- >Comment By: Jeff Jensen (jeffjensen) Date: 2012-04-15 09:12 Message: Duplicate of 3071408. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3452801&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-04-15 16:01:53
|
Bugs item #3516309, was opened at 2012-04-09 23:26 Message generated for change (Comment added) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3516309&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* Status: Open Resolution: None Priority: 7 Private: No Submitted By: Marcel H (marcelhoerr) >Assigned to: Jeff Jensen (jeffjensen) Summary: Debug statement in AbstractDatabaseConnection causing NSOE Initial Comment: The second debug statement in the <b>createQueryTable</b> method of the class <b>AbstractDatabaseConnection</b> (line 91) is always causing an UnsupportedOperationException. The debug statment is using the interface method <b>getRowCount</b> of <b>ITable</b>, though the underlying class is always a <b>ForwardOnlyResultSetTable</b> which does not support the <b>getRowCount</b> method. Possible fixes: (1) Use the public method <b>getRowCount</b> of <b>AbstractDatabaseConnection</b> for the debug statement instead. (2) Remove the debug statement. ---------------------------------------------------------------------- >Comment By: Jeff Jensen (jeffjensen) Date: 2012-04-15 09:01 Message: Nice find, thanks for reporting. Will you please attach a test(s) exhibiting the problem and a patch fixing please (keeping the intended info)? I will apply... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3516309&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-04-10 06:27:48
|
Bugs item #3516309, was opened at 2012-04-09 23:26 Message generated for change (Settings changed) made by marcelhoerr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3516309&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Marcel H (marcelhoerr) Assigned to: matthias g (gommma) Summary: Debug statement in AbstractDatabaseConnection causing NSOE Initial Comment: The second debug statement in the <b>createQueryTable</b> method of the class <b>AbstractDatabaseConnection</b> (line 91) is always causing an UnsupportedOperationException. The debug statment is using the interface method <b>getRowCount</b> of <b>ITable</b>, though the underlying class is always a <b>ForwardOnlyResultSetTable</b> which does not support the <b>getRowCount</b> method. Possible fixes: (1) Use the public method <b>getRowCount</b> of <b>AbstractDatabaseConnection</b> for the debug statement instead. (2) Remove the debug statement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3516309&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-04-10 06:26:18
|
Bugs item #3516309, was opened at 2012-04-09 23:26 Message generated for change (Tracker Item Submitted) made by marcelhoerr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3516309&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcel H (marcelhoerr) Assigned to: matthias g (gommma) Summary: Debug statement in AbstractDatabaseConnection causing NSOE Initial Comment: The second debug statement in the <b>createQueryTable</b> method of the class <b>AbstractDatabaseConnection</b> (line 91) is always causing an UnsupportedOperationException. The debug statment is using the interface method <b>getRowCount</b> of <b>ITable</b>, though the underlying class is always a <b>ForwardOnlyResultSetTable</b> which does not support the <b>getRowCount</b> method. Possible fixes: (1) Use the public method <b>getRowCount</b> of <b>AbstractDatabaseConnection</b> for the debug statement instead. (2) Remove the debug statement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3516309&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-03-08 12:24:29
|
Bugs item #3499513, was opened at 2012-03-08 04:24 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3499513&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Feature Request Group: v2.4.* Status: Open Resolution: None Priority: 5 Private: No Submitted By: MPriess () Assigned to: Roberto Lo Giacco (rlogiacco) Summary: Postgis Geometry Type Initial Comment: Based on the Code from Benoit PESTY posted on the mailingliste. I created a patch which added the Geometry Datatype used from PostGis into DBUnit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3499513&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-02-13 09:49:03
|
Feature Requests item #3487212, was opened at 2012-02-13 01:49 Message generated for change (Tracker Item Submitted) made by macha64 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3487212&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Masaaki Takahashi (macha64) Assigned to: Nobody/Anonymous (nobody) Summary: Patch: Export Ant Task supports "useCharacterReference" Initial Comment: Hi Export Ant Task writes "CharacterReference" from "Multibyte character".(e.g. 葡萄) it is inconvenient for multibyte character user. so, i add "useCharacterReference" for Export Ant Task. <export dest="export.xml" format="flat" useCharacterReference="false"> <query name="FRUIT_TBL" sql="select * from FRUIT_TBL order by FRUIT_UID"/> </export> thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3487212&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-01-25 13:41:21
|
Bugs item #3479543, was opened at 2012-01-25 02:17 Message generated for change (Comment added) made by chrisphe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3479543&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tobias Buchloh (tbuchloh) Assigned to: Jeff Jensen (jeffjensen) Summary: TimestampDataType cannot typeCast correct Timestamp strings Initial Comment: = Problem = We want to migrate dbunit from v2.2 to v2.4.8 and are now faced with the problem that some of our test cases do not work anymore due to changes in org.dbunit.dataset.datatype.TimestampDataType.typeCast(Object). In v2.2 the string "2010-05-19 08:38:45.123456" was converted into a correct java.sql.Timestamp-object. With v2.4.8 it will be converted silently to "2010-05-19 08:40:48.456" which is definitely not what we expected. = Possible cause = Looking in the code we found a problem beginning on line 91: <snip> try { // SimpleDateFormat uses millisecond precision only DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS"); Date date = df.parse(stringValue); return new java.sql.Timestamp(date.getTime()); } catch (ParseException e) { if (i < patterns.length) continue; throw new TypeCastException(value, this, e); } </snap> Using SimpleDateFormat for a nano precision type does not work, because it creates a java.util.Date-object which does not work with nanoseconds. In v2.2 the method Timestamp.valueOf(String) has been used. ---------------------------------------------------------------------- Comment By: Chris Pheby (chrisphe) Date: 2012-01-25 05:41 Message: This bug is the same as [3452801] TimestampDataType cannot parse java.sql.Timestamp.toString [3071408] New Handling of Timestamp in 2.4.8 has error with subseconds I already submitted a patch for this ((the patch was applied to trunk in February last year) - See the issue at https://sourceforge.net/tracker/?func=detail&aid=3071408&group_id=47439&atid=449491 This bug makes 2.4.8 unusable for anyone working with timestamps, is there any chance a 2.4.9 release can be made from the trunk after this patch was applied ? Thanks Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3479543&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-01-25 13:19:22
|
Bugs item #3479543, was opened at 2012-01-25 02:17 Message generated for change (Comment added) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3479543&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tobias Buchloh (tbuchloh) >Assigned to: Jeff Jensen (jeffjensen) Summary: TimestampDataType cannot typeCast correct Timestamp strings Initial Comment: = Problem = We want to migrate dbunit from v2.2 to v2.4.8 and are now faced with the problem that some of our test cases do not work anymore due to changes in org.dbunit.dataset.datatype.TimestampDataType.typeCast(Object). In v2.2 the string "2010-05-19 08:38:45.123456" was converted into a correct java.sql.Timestamp-object. With v2.4.8 it will be converted silently to "2010-05-19 08:40:48.456" which is definitely not what we expected. = Possible cause = Looking in the code we found a problem beginning on line 91: <snip> try { // SimpleDateFormat uses millisecond precision only DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS"); Date date = df.parse(stringValue); return new java.sql.Timestamp(date.getTime()); } catch (ParseException e) { if (i < patterns.length) continue; throw new TypeCastException(value, this, e); } </snap> Using SimpleDateFormat for a nano precision type does not work, because it creates a java.util.Date-object which does not work with nanoseconds. In v2.2 the method Timestamp.valueOf(String) has been used. ---------------------------------------------------------------------- >Comment By: Jeff Jensen (jeffjensen) Date: 2012-01-25 05:19 Message: Thank you for finding the problem. Please attach tests and a patch and I will apply to trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3479543&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-01-25 10:17:24
|
Bugs item #3479543, was opened at 2012-01-25 02:17 Message generated for change (Tracker Item Submitted) made by tbuchloh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3479543&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tobias Buchloh (tbuchloh) Assigned to: matthias g (gommma) Summary: TimestampDataType cannot typeCast correct Timestamp strings Initial Comment: = Problem = We want to migrate dbunit from v2.2 to v2.4.8 and are now faced with the problem that some of our test cases do not work anymore due to changes in org.dbunit.dataset.datatype.TimestampDataType.typeCast(Object). In v2.2 the string "2010-05-19 08:38:45.123456" was converted into a correct java.sql.Timestamp-object. With v2.4.8 it will be converted silently to "2010-05-19 08:40:48.456" which is definitely not what we expected. = Possible cause = Looking in the code we found a problem beginning on line 91: <snip> try { // SimpleDateFormat uses millisecond precision only DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS"); Date date = df.parse(stringValue); return new java.sql.Timestamp(date.getTime()); } catch (ParseException e) { if (i < patterns.length) continue; throw new TypeCastException(value, this, e); } </snap> Using SimpleDateFormat for a nano precision type does not work, because it creates a java.util.Date-object which does not work with nanoseconds. In v2.2 the method Timestamp.valueOf(String) has been used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3479543&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2012-01-10 17:04:28
|
Feature Requests item #3471931, was opened at 2012-01-10 09:04 Message generated for change (Tracker Item Submitted) made by ialvarez79 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3471931&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ignacio Alvarez (ialvarez79) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid CyclicTablesDependencyException Initial Comment: I found a way to avoid CyclicTablesDependencyException (maybe I'm missing some part of the problem). This could be as simple (maybe some configurable item), to split the dataset in two datasets. The first will do the inserts, having problematic fields in null. The second dataset will then update the records, defining dependencies according to our needs. (This is the natural way I do this stuff when I have to insert cyclic data manually) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3471931&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2011-12-29 11:06:40
|
Feature Requests item #3147832, was opened at 2010-12-29 14:09 Message generated for change (Comment added) made by davidwery You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3147832&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Next Release Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ralf Mühle (ralfmuehle) Assigned to: Nobody/Anonymous (nobody) Summary: Update DBunit to POI 3.7 Initial Comment: Hi I've created a svn-patch to update the last release of DBUnit to POI 3.7. Please check it and if you think that is good you could use it Best regards, Ralf ---------------------------------------------------------------------- Comment By: David Wery (davidwery) Date: 2011-12-29 03:06 Message: We really need the support of POI (at least 3.6). In our project (using Maven), we have conflicts between POI 3.6 (needed for xlsx support) and the usage of DBUnit (which use POI 3.2-Final). Is it possible to have a binary form the DBUnit with the proposed patch of ralfmuehle ? Thx ---------------------------------------------------------------------- Comment By: Andrew Spencer () Date: 2011-11-02 03:36 Message: Our production code needs POI 3.7. With Maven it isn't possible to use 3.2 in the DBUnit tests and 3.7 in the production code, because the test classpath supplements the main classpath. I am sure there are other users in this situation. ---------------------------------------------------------------------- Comment By: Ralf Mühle (ralfmuehle) Date: 2010-12-30 02:56 Message: Yes there is a reasen: We need Support of the new Excel format so that we can load huge excel files. More than 66000 lines and we get the (testing) data in the new excel format The patch I've created is an example how you can support both format,s the old and the new one. ---------------------------------------------------------------------- Comment By: Roberto Lo Giacco (rlogiacco) Date: 2010-12-30 02:10 Message: Is there any specific reason for the update? Any missing feature, solved bug or anything like that? Usually upgrades for the sake to stay on most recent version are not convenient: they tend to break instead to solve... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3147832&group_id=47439 |
|
From: Chris P. <ch...@ja...> - 2011-12-07 15:50:50
|
Hi Ken, I submitted a patch which was applied to trunk some time ago which I think fixes this issue, in which case this should be closed as a duplicate. A build with the patch (which is post 2.4.8) has not yet been released though. See the issue at https://sourceforge.net/tracker/?func=detail&aid=3071408&group_id=47439&atid=449491 Regards Chris -----Original Message----- From: SourceForge.net [mailto:no...@so...] Sent: 07 December 2011 00:12 To: SourceForge.net Subject: [dbunit-developer] [ dbunit-Bugs-3452801 ] TimestampDataType cannot parse java.sql.Timestamp.toString Bugs item #3452801, was opened at 2011-12-06 13:11 Message generated for change (Tracker Item Submitted) made by kenhuffman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3452801&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ken Huffman (kenhuffman) Assigned to: matthias g (gommma) Summary: TimestampDataType cannot parse java.sql.Timestamp.toString Initial Comment: java.sql.Timestamp.toString() will trim trailing zeros with fractional seconds. E.g. 780 milliseconds is written "12:34:56.78" instead of "12:34:56.780" Unfortunately TimestampDataType.typeCast() parses "12:34:56.78" incorrectly as 78 milliseconds (i.e. "12:34:56.078") instead of the correct 780 milliseconds. This causes FlatXmlDatSetBuilder to incorrectly interpret files written by FlatXmlWriter when they contain timestamps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3452801&group_id=47439 ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ dbunit-developer mailing list dbu...@li... https://lists.sourceforge.net/lists/listinfo/dbunit-developer |
|
From: SourceForge.net <no...@so...> - 2011-12-07 15:05:40
|
Feature Requests item #3452467, was opened at 2011-12-06 07:06 Message generated for change (Comment added) made by kenhuffman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3452467&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ken Huffman (kenhuffman) Assigned to: Nobody/Anonymous (nobody) Summary: SortedDataSet Initial Comment: SortedDatSet.getTable should support setting the setUseComparable() flag when it creates SortedTables. ---------------------------------------------------------------------- >Comment By: Ken Huffman (kenhuffman) Date: 2011-12-07 07:05 Message: The SortedDataSet$SortedIterator.getTable() should also set the setUseComparable() flag ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3452467&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2011-12-06 21:11:50
|
Bugs item #3452801, was opened at 2011-12-06 13:11 Message generated for change (Tracker Item Submitted) made by kenhuffman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3452801&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bug Group: v2.4.* Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ken Huffman (kenhuffman) Assigned to: matthias g (gommma) Summary: TimestampDataType cannot parse java.sql.Timestamp.toString Initial Comment: java.sql.Timestamp.toString() will trim trailing zeros with fractional seconds. E.g. 780 milliseconds is written "12:34:56.78" instead of "12:34:56.780" Unfortunately TimestampDataType.typeCast() parses "12:34:56.78" incorrectly as 78 milliseconds (i.e. "12:34:56.078") instead of the correct 780 milliseconds. This causes FlatXmlDatSetBuilder to incorrectly interpret files written by FlatXmlWriter when they contain timestamps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449491&aid=3452801&group_id=47439 |
|
From: SourceForge.net <no...@so...> - 2011-12-06 15:06:41
|
Feature Requests item #3452467, was opened at 2011-12-06 07:06 Message generated for change (Tracker Item Submitted) made by kenhuffman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3452467&group_id=47439 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ken Huffman (kenhuffman) Assigned to: Nobody/Anonymous (nobody) Summary: SortedDataSet Initial Comment: SortedDatSet.getTable should support setting the setUseComparable() flag when it creates SortedTables. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=449494&aid=3452467&group_id=47439 |
23 messages has been excluded from this view by a project administrator.
