> -----Message d'origine----- > De : fpc-pascal-boun...@lists.freepascal.org > [mailto:fpc-pascal-boun...@lists.freepascal.org] De la part > de Reinier Olislagers > Envoyé : jeudi 28 juillet 2011 16:29 > À : FPC Mailing list > Objet : [fpc-pascal] XML-XSD export: importer & how to test > > > On 28-7-2011 15:13, Reinier Olislagers wrote: > > On 28-7-2011 14:36, Ludo Brands wrote: > > > > I'll get to the issues some time after the test framework > > improvements. > > > > If you prefer to, please feel free to directly enter the issues: > > https://bitbucket.org/reiniero/fpc_laz_patch_playground/issues/new > > > > In addition, I could also give you write access to the bitbucket > > mercurial repository... > > > > Regards, > > Reinier > 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.
> Another solution would be to verify the xml output, but then > you're basically writing an importer for the export format ;) > Could be worthwile in the case of Delphi Clientdataset though... > A different export output doesn't mean that the importing application imports something different. The final test is importing in a foreign application. > Any thoughts on how to improve the tests? > > 4. Would it actually make sense to start an importer project > that imports e.g. clientdataset, csv, into a dataset? Is > there already something like that? > > 5. I briefly thought about including OpenOffice Calc (ODT) > format exporting but that seems a bit overkill as there > already is a CSV export format. Any thoughts on new formats - > apart from Atom ;) ? > IMHO making additional specific exporters for calc / excel type of applications isn't very usefull. Spreadsheets don't have real typed data and can infer quite well a "schema" for xml data that don't contain one. The XML data these apps export contain more presentation type of info than data type related info. As you wrote, csv is good enough for these apps and has far less overhead. Ludo > Thanks, > 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
