Re: RE : [fpc-pascal] XML-XSD export: importer & how to test
On 28-7-2011 18:02, Ludo Brands wrote: >> 3. Regarding the tests: I thought about better ways of >> testing the exports. The only fairly easy way I see is >> testing with more databases (such as mysql which you were >> doing), maybe by adapting the existing fcl-db test framework. >> Haven't ever run that though, but I can learn ;) >> > I used mysql because I have some testtables in mysql that contain almost all > mysql types which I used in another project. Downside is that you test as > well the sqldb mysql implementation as the export. IMHO building testcases > with MemDataset using the different built-in datatypes and border-line > values (limit values for integers, special characters in strings, etc.) is > going to be a cleaner solution. Will make regression testion also easier. Agreed, but you cannot every kind of data type, for that you will probably need the various databases... and hopefully a continuous integration server to run the tests... But yes, you're then testing the fcl-db drivers/framework as much as the export functionality. Not a completely bad thing. Whenever you have time, could you send me a dump of the table definition with or without data? That would save me doing that... Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : [fpc-pascal] XML-XSD export: importer & how to test
> Agreed, but you cannot every kind of data type, for that you > will probably need the various databases... and hopefully a > continuous integration server to run the tests... > Sqldb converts databases types to the internal ftxxx datatypes. So, yes, you can everything without external databases. > But yes, you're then testing the fcl-db drivers/framework as > much as the export functionality. Not a completely bad thing. > Testing multiple layers at the same time is always dificult since interpreting errors is complex. Unit testing was invented for that purpose. > Whenever you have time, could you send me a dump of the table > definition with or without data? That would save me doing that... > No problem. Here it comes: CREATE TABLE `testodbc` ( `id` int(11) NOT NULL auto_increment, `s_int` int(11) default NULL, `u_int` int(10) unsigned default NULL, `s_tinyint` tinyint(4) default NULL, `u_tinyint` tinyint(3) unsigned default NULL, `s_smallint` smallint(6) default NULL, `u_smallint` smallint(5) unsigned default NULL, `s_mediumint` mediumint(9) default NULL, `u_mediumint` mediumint(8) unsigned default NULL, `s_bigint` bigint(20) default NULL, `u_bigint` bigint(20) unsigned default NULL, `t_float` float default NULL, `t_double` double default NULL, `t_decimal` decimal(10,4) default NULL, `t_datetime` datetime default NULL, `t_date` date default NULL, `t_timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP, `t_time` time default NULL, `t_year` year(4) default NULL, `l_char1` char(1) character set latin1 collate latin1_general_cs default NULL, `u_char1` char(1) character set utf8 collate utf8_bin default NULL, `l_char20` char(20) character set latin1 collate latin1_general_cs default NULL, `u_char20` char(20) character set utf8 collate utf8_bin default NULL, `l_varchar10` varchar(10) character set latin1 collate latin1_general_cs default NULL, `u_varchar10` varchar(10) character set utf8 collate utf8_bin default NULL, `l_varchar300` varchar(300) character set latin1 collate latin1_general_cs default NULL, `u_varchar300` varchar(300) character set utf8 collate utf8_bin default NULL, `l_tinytext` tinytext character set latin1 collate latin1_general_cs, `u_tinytext` tinytext character set utf8 collate utf8_bin, `u_mediumtext` mediumtext character set utf8 collate utf8_bin, `u_text` text character set utf8 collate utf8_bin, `u_longtext` longtext character set utf8 collate utf8_bin, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci Note the u_char1 which is too small to hold a multiple byte utf character! Ludo > Reinier > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] XML-XSD export: importer & how to test
On 28-7-2011 20:27, Ludo Brands wrote: > >> Agreed, but you cannot every kind of data type, for that you >> will probably need the various databases... and hopefully a >> continuous integration server to run the tests... >> > > Sqldb converts databases types to the internal ftxxx datatypes. So, yes, you > can everything without external databases. I admit I need to delve deeper into this, but to me it's strange we have datatypes like ftOracleBlob and ftParadoxOLE... These do seem to be database-specific (ok, maybe within fcl-db, but still). Earlier today I've written code to dumbly create a bufdataset with all these datatypes for and will see what happens when assigning data to it. If it blows, I'll comment it out... we'll see. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : [fpc-pascal] XML-XSD export: importer & how to test
> >> Agreed, but you cannot every kind of data type, for that you > >> will probably need the various databases... and hopefully a > >> continuous integration server to run the tests... > >> > > > > Sqldb converts databases types to the internal ftxxx datatypes. So, > > yes, you can everything without external databases. > I admit I need to delve deeper into this, but to me it's > strange we have datatypes like ftOracleBlob and > ftParadoxOLE... These do seem to be database-specific (ok, > maybe within fcl-db, but still). Earlier today I've written > code to dumbly create a bufdataset with all these datatypes > for and will see what happens when assigning data to it. If > it blows, I'll comment it out... we'll see. Db.pas line 2020 gives you the mapping between ftxxx and corresponding Tfield descendant. This is a default mapping but AFAIK no db implementation is actually overriding this. Since there are a lot of ftxxx mapped to only a few TField classes, the testcases can be reduced considerably. It'll help also in reducing the long 'case fieldtype' statements you have now. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : [fpc-pascal] XML-XSD export: importer & how to test
On 28-7-2011 20:59, Ludo Brands wrote: Agreed, but you cannot every kind of data type, for that you will probably need the various databases... and hopefully a continuous integration server to run the tests... >>> >>> Sqldb converts databases types to the internal ftxxx datatypes. So, >>> yes, you can everything without external databases. >> I admit I need to delve deeper into this, but to me it's >> strange we have datatypes like ftOracleBlob and >> ftParadoxOLE... These do seem to be database-specific (ok, >> maybe within fcl-db, but still). Earlier today I've written >> code to dumbly create a bufdataset with all these datatypes >> for and will see what happens when assigning data to it. If >> it blows, I'll comment it out... we'll see. > > Db.pas line 2020 gives you the mapping between ftxxx and corresponding > Tfield descendant. This is a default mapping but AFAIK no db implementation > is actually overriding this. > Since there are a lot of ftxxx mapped to only a few TField classes, the > testcases can be reduced considerably. It'll help also in reducing the long > 'case fieldtype' statements you have now. > Thanks, I'll have a look... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : [fpc-pascal] XML-XSD export: importer & how to test
On Thu, 28 Jul 2011, Ludo Brands wrote: Agreed, but you cannot every kind of data type, for that you will probably need the various databases... and hopefully a continuous integration server to run the tests... Sqldb converts databases types to the internal ftxxx datatypes. So, yes, you can everything without external databases. I admit I need to delve deeper into this, but to me it's strange we have datatypes like ftOracleBlob and ftParadoxOLE... These do seem to be database-specific (ok, maybe within fcl-db, but still). Earlier today I've written code to dumbly create a bufdataset with all these datatypes for and will see what happens when assigning data to it. If it blows, I'll comment it out... we'll see. Db.pas line 2020 gives you the mapping between ftxxx and corresponding Tfield descendant. This is a default mapping but AFAIK no db implementation is actually overriding this. Not in FPC, but in Delphi, IBX for instance overrides it. Maybe mseide does it too. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : [fpc-pascal] XML-XSD export: importer & how to test
On 29-7-2011 9:27, michael.vancann...@wisa.be wrote: > > > On Thu, 28 Jul 2011, Ludo Brands wrote: > > Agreed, but you cannot every kind of data type, for that you > will probably need the various databases... and hopefully a > continuous integration server to run the tests... > Sqldb converts databases types to the internal ftxxx datatypes. So, yes, you can everything without external databases. >>> I admit I need to delve deeper into this, but to me it's >>> strange we have datatypes like ftOracleBlob and >>> ftParadoxOLE... These do seem to be database-specific (ok, >>> maybe within fcl-db, but still). Earlier today I've written >>> code to dumbly create a bufdataset with all these datatypes >>> for and will see what happens when assigning data to it. If >>> it blows, I'll comment it out... we'll see. >> >> Db.pas line 2020 gives you the mapping between ftxxx and corresponding >> Tfield descendant. This is a default mapping but AFAIK no db >> implementation >> is actually overriding this. > > Not in FPC, but in Delphi, IBX for instance overrides it. > Maybe mseide does it too. > > Michael. Ok, just to be safe and document mappings in any event, I'll keep the complete list of mappings in the exporter. I'll only test with the types that work in a bufdataset... Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : [fpc-pascal] XML-XSD export: importer & how to test
Am 29.07.2011 08:27, schrieb michael.vancann...@wisa.be: Maybe mseide does it too. Correct. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
