Menu
▾
▴
Re: [dbunit-developer] dbUnit 3: drop the "I" prefix for interfaces
|
From: Roberto Lo G. <rlo...@gm...> - 2010-12-28 07:59:15
|
I think we have a few key arguments to solve on the 3.0 and one of them is case sensitiveness... Il giorno 28/dic/2010, alle ore 07:05, John Hurst <joh...@gm...> ha scritto: Hello. Here's a list of the interfaces currently in DbUnit trunk: org.dbunit.IDatabaseTester org.dbunit.IOperationListener org.dbunit.PrepAndExpectedTestCase org.dbunit.ant.DbUnitTaskStep org.dbunit.assertion.DifferenceListener org.dbunit.assertion.FailureFactory org.dbunit.assertion.FailureHandler org.dbunit.database.IDatabaseConnection org.dbunit.database.IMetadataHandler org.dbunit.database.IResultSetTable org.dbunit.database.IResultSetTableFactory org.dbunit.database.statement.IBatchStatement org.dbunit.database.statement.IPreparedBatchStatement org.dbunit.database.statement.IStatementFactory org.dbunit.dataset.IDataSet org.dbunit.dataset.IRowValueProvider org.dbunit.dataset.ITable org.dbunit.dataset.ITableIterator org.dbunit.dataset.ITableMetaData org.dbunit.dataset.common.handlers.Handler org.dbunit.dataset.common.handlers.PipelineComponent org.dbunit.dataset.csv.CsvParser org.dbunit.dataset.datatype.IDataTypeFactory org.dbunit.dataset.datatype.IDbProductRelatable org.dbunit.dataset.filter.IColumnFilter org.dbunit.dataset.filter.IRowFilter org.dbunit.dataset.filter.ITableFilter org.dbunit.dataset.filter.ITableFilterSimple org.dbunit.dataset.sqlloader.SqlLoaderControlParser org.dbunit.dataset.stream.IDataSetConsumer org.dbunit.dataset.stream.IDataSetProducer org.dbunit.util.concurrent.BoundedChannel org.dbunit.util.concurrent.Channel org.dbunit.util.concurrent.Executor org.dbunit.util.concurrent.Puttable org.dbunit.util.concurrent.Sync org.dbunit.util.concurrent.Takable org.dbunit.util.fileloader.DataFileLoader org.dbunit.util.search.IEdge org.dbunit.util.search.ISearchAlgorithm org.dbunit.util.search.ISearchCallback It seems that (almost) all of the "core" packages use the "I" prefix convention, and a lot of the peripheral and some recently-added stuff does not use that convention. Here are what I think are the "key" interfaces: IDataSet ITable ITableMetaData IDataSet is basically right. But if I were doing it over again, I would consider: - Changing array returns to Iterable: getTableNames() should return Iterable<String> and getTables() should return Iterable<ITable>. - Moving isCaseSensitiveTableNames elsewhere. This probably should be in a DataSetMetaData class or something like that. This method just seems out of place in relation to other methods in this interface, though I could be wrong. ITable -- I don't think this interface will change in DbUnit 3.0. ITableMetaData -- again, return types could be Iterable<Column> instead of Column[] etc. So from these examples, we see that there is potential for breaking changes in some of the most core interfaces, depending on how far you want to go with a complete Java5 overhaul of this code. This is a big job. If we start breaking that much stuff, it's going to be hard work to continue to support all of the accumulated functionality. There are many features in DbUnit that I've never used, and may not have test coverage. We have our work cut out for us to continue to support those features. On the other hand, we could start with a "fresh" slate, a cleaner architecture and a cleaner code base, and that might result in a good 3.0 release for a "new beginning". This will work best if the team has a common vision of where we want to go with it. I'm not sure we've reached that point as a team yet. But I guess that's where I'd like to get to. Enough on that subject from me, for this post! Regards John Hurst On Tue, Dec 28, 2010 at 5:03 AM, Roberto Lo Giacco <rlo...@gm...>wrote: > Hi John, > how is your back? > > On Mon, Dec 27, 2010 at 09:39, John Hurst <joh...@gm...> wrote: > >> If we're going to break most of the interfaces anyway, then I would agree >> with this change, because I prefer interface names *not* to start with an >> extra 'I'. >> >> On the other hand, if we are leaving most of the interfaces just as they >> are today, then I feel that it's not worth the disruption. >> > > I agree, I'll start naming interfaces without the "I" prefix and then we'll > decide if it's worth or not. > > I will have a look through the interfaces tomorrow to see how many I think >> would change. I guess we need to compile a list of API changes for the >> documentation. >> > > Agreed, I would name that document "Migrating from previous versions" > > >> What is the status of our project hosting now? Where is the master code >> repo? >> > > Actually I'm starting using codehaus for the 3.0 branch leaving actual > codebase on Sourceforge. We can eventually migrate everything to codehaus if > and when we decide to. > > I've still committed nothing to codehaus yet, but I think I'll populate > that subversion repo in a couple of days. Do not expect much anyway... > > I think we can start working on installing systems for integration test for > both codebase: the actual one and the next gen... > > >> Regards >> >> JH >> >> On Mon, Dec 27, 2010 at 8:35 PM, Roberto Lo Giacco <rlo...@gm...>wrote: >> >>> Hi all, >>> I wish to know your opinion on dropping the I prefix for interfaces >>> currently used in the dbUnit 2.x codebase. This will introduce a great >>> change and greatly break backward compatibility with a small improvement, in >>> my opinion, in API naming. >>> Do you think it is worth the change? I'm doubtful myself... >>> >>> >>> ------------------------------------------------------------------------------ >>> Learn how Oracle Real Application Clusters (RAC) One Node allows >>> customers >>> to consolidate database storage, standardize their database environment, >>> and, >>> should the need arise, upgrade to a full multi-node Oracle RAC database >>> without downtime or disruption >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> dbunit-developer mailing list >>> dbu...@li... >>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer >>> >>> >> >> >> -- >> Life is interfering with my game >> >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, >> and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> dbunit-developer mailing list >> dbu...@li... >> https://lists.sourceforge.net/lists/listinfo/dbunit-developer >> >> > > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, > and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > dbunit-developer mailing list > dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbunit-developer > > -- Life is interfering with my game ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ dbunit-developer mailing list dbu...@li... https://lists.sourceforge.net/lists/listinfo/dbunit-developer |
