Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On 28-7-2011 9:24, michael.vancann...@wisa.be wrote:
On Thu, 28 Jul 2011, Reinier Olislagers wrote:
On 27-7-2011 20:52, michael.vancann...@wisa.be wrote:
Code like
ftWideString: //fixed length or at least max length string
begin
TDOMElement(ColumnNode).SetAttribute('fieldtype', 'string');
TDOMElement(ColumnNode).SetAttribute('WIDTH',
UTF8Decode(string(ExportFields.Fields[ItemCounter].Field.Size)));
end;
Regarding the snippet above: for Unicode-enabled Delphis, using
Clientdataset savetofile as UTF8-based XML (dfXMLUTF8), what do I need
to output for a ftString:
- Field.Size (number of characters in string)
- Field.DataSize (number of bytes in string field)
As Michael indicated, it probably is Field.Size, but I'd like to have
that confirmed. (Can't seem to find any documentation on ClientDataset
XML format on Embarcadero's Delphi help at
http://docwiki.embarcadero.com/VCL/en/DBClient.TCustomClientDataSet.SaveToFile)
Thanks,
Reinier
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On Mon, 15 Aug 2011, Reinier Olislagers wrote:
On 28-7-2011 9:24, michael.vancann...@wisa.be wrote:
On Thu, 28 Jul 2011, Reinier Olislagers wrote:
On 27-7-2011 20:52, michael.vancann...@wisa.be wrote:
Code like
ftWideString: //fixed length or at least max length string
begin
TDOMElement(ColumnNode).SetAttribute('fieldtype', 'string');
TDOMElement(ColumnNode).SetAttribute('WIDTH',
UTF8Decode(string(ExportFields.Fields[ItemCounter].Field.Size)));
end;
Regarding the snippet above: for Unicode-enabled Delphis, using
Clientdataset savetofile as UTF8-based XML (dfXMLUTF8), what do I need
to output for a ftString:
- Field.Size (number of characters in string)
- Field.DataSize (number of bytes in string field)
As Michael indicated, it probably is Field.Size, but I'd like to have
that confirmed. (Can't seem to find any documentation on ClientDataset
XML format on Embarcadero's Delphi help at
http://docwiki.embarcadero.com/VCL/en/DBClient.TCustomClientDataSet.SaveToFile)
I created a dataset with 2 fields. A ftString field with size 33, and a
ftWideString field with size 44.
Based on the following output from SaveToFile, I would say that you'll need to put
Size*SizeOf(CharTypeUsedInfield), which should be DataSize.
Michael.
?xml version=1.0 encoding=UTF-8 standalone=yes?
DATAPACKET Version=2.0
METADATA
FIELDS
FIELD attrname=stringveld fieldtype=string WIDTH=33/
FIELD attrname=WideStringVeld fieldtype=string.uni WIDTH=44/
/FIELDS
PARAMS/
/METADATA
ROWDATA
/ROWDATA
/DATAPACKET
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On 15-8-2011 11:25, Michael Van Canneyt wrote: I created a dataset with 2 fields. A ftString field with size 33, and a ftWideString field with size 44. Based on the following output from SaveToFile, I would say that you'll need to put Size*SizeOf(CharTypeUsedInfield), which should be DataSize. Michael. ?xml version=1.0 encoding=UTF-8 standalone=yes? DATAPACKET Version=2.0 METADATA FIELDS FIELD attrname=stringveld fieldtype=string WIDTH=33/ FIELD attrname=WideStringVeld fieldtype=string.uni WIDTH=44/ /FIELDS PARAMS/ /METADATA ROWDATA /ROWDATA /DATAPACKET Thanks, Michael, Set to .DataSize... I'm ready for uploading this for inclusion in FPC, I can open a bugreport and attach the patch if you're happy with that. Fixes/changes since first commit to FPC === 1. Code cleanup to make it more modular and maintainable: split out code per export format and moved class-level variables there. 2. Delphi Clientdataset export now works thanks to FPC XML fixes by Sergei Gorelkin and tests/improvements by Ludo Brands. 3. Extended test coverage with all field types in a BufDataset so tests cover more. 4. Fixes for invalid data: Access, ADO.Net, Excel date limits respected (generate NULL or text fields respectively) 5. Decimalseparator setting in Access export should now work. 6. Variants are saved as blobs, not strings, because of their variable nature. 7. Fix for proper export of null values to Access NULL values (instead of empty/default values). 8. Changed description of class from Unicode XML file with XSD to Unicode XML file to better match unit function. 9. Compiled on Windows x86, Linux x64 without warnings using fpc -vweh fpxmlxsdexport.pp. Compared output. - ftVarBytes gave different output on Windows Linux. Disregarded as I don't fill these fields in the test because of bug 19930 10. Added option KeepFilesAfterTest = true in xmlxsdexporttestcase1; can be switched to false to delete export test files after use. 11. Lower-cased source code file names. 12. Fixes for Linux invalid date export to Excel by using clocale and specifying dateformat (restored at end of export). 13 .Datasize instead of .Size for string/widestring Delphi fields. Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On 15-8-2011 11:44, Reinier Olislagers wrote: On 15-8-2011 11:25, Michael Van Canneyt wrote: I created a dataset with 2 fields. A ftString field with size 33, and a ftWideString field with size 44. Based on the following output from SaveToFile, I would say that you'll need to put Size*SizeOf(CharTypeUsedInfield), which should be DataSize. Michael. ?xml version=1.0 encoding=UTF-8 standalone=yes? DATAPACKET Version=2.0 METADATA FIELDS FIELD attrname=stringveld fieldtype=string WIDTH=33/ FIELD attrname=WideStringVeld fieldtype=string.uni WIDTH=44/ /FIELDS PARAMS/ /METADATA ROWDATA /ROWDATA /DATAPACKET Thanks, Michael, Set to .DataSize... I'm ready for uploading this for inclusion in FPC, I can open a bugreport and attach the patch if you're happy with that. Decided to upload it - I think it's a great improvement compared to the original code. Unfortunately that has more to do with my skills and other peoples' help, but well... better code is better code :) Uploaded as issue 19987. Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On Mon, 15 Aug 2011, Reinier Olislagers wrote: On 15-8-2011 11:44, Reinier Olislagers wrote: On 15-8-2011 11:25, Michael Van Canneyt wrote: I created a dataset with 2 fields. A ftString field with size 33, and a ftWideString field with size 44. Based on the following output from SaveToFile, I would say that you'll need to put Size*SizeOf(CharTypeUsedInfield), which should be DataSize. Michael. ?xml version=1.0 encoding=UTF-8 standalone=yes? DATAPACKET Version=2.0 METADATA FIELDS FIELD attrname=stringveld fieldtype=string WIDTH=33/ FIELD attrname=WideStringVeld fieldtype=string.uni WIDTH=44/ /FIELDS PARAMS/ /METADATA ROWDATA /ROWDATA /DATAPACKET Thanks, Michael, Set to .DataSize... I'm ready for uploading this for inclusion in FPC, I can open a bugreport and attach the patch if you're happy with that. Decided to upload it - I think it's a great improvement compared to the original code. Unfortunately that has more to do with my skills and other peoples' help, but well... better code is better code :) Uploaded as issue 19987. I applied the patch, thank you very much for this work :-). But please: - Try to split patches in smaller chunks. It's better for bugfixing. If you break something it's harder to track what caused the break with these huge patches. - Please send diffs. - Don't change casing of files in between patches. (should be no problem if you send diffs, actually) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On 15-8-2011 12:33, michael.vancann...@wisa.be wrote: I applied the patch, thank you very much for this work :-). But please: - Try to split patches in smaller chunks. It's better for bugfixing. If you break something it's harder to track what caused the break with these huge patches. Ok - and I thought it would be less work for you guys to apply it if I submitted one big one ;) - Please send diffs. Ok. - Don't change casing of files in between patches. (should be no problem if you send diffs, actually) Mmm, tried to help there, by lowercasing everything... Thanks a lot, my itch has been scratched for now - back to developing the program that was actually meant to use this functionality. Of course, bug reports/improvement suggestions still welcome; I'll try and submit small patches for them ;) Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On Thu, 28 Jul 2011, Reinier Olislagers wrote:
On 27-7-2011 20:52, michael.vancann...@wisa.be wrote:
On Wed, 27 Jul 2011, Reinier Olislagers wrote:
Update: includes first stab at Delphi Clientdataset. Please test with
various datatypes as I haven't been able to map all of them...
I added your implementation to SVN.
Thanks, Michael.
I noticed your remark on a failing conversion of a longint to a string -
that code wouldn't have worked. Obviously a priority to increase the
test coverage.
But you may want to check your implementation on 64-bit prior to
submitting.
I will compile test on Linux x64 before submitting an upgrade
Code like
ftWideString: //fixed length or at least max length string
begin
TDOMElement(ColumnNode).SetAttribute('fieldtype', 'string');
TDOMElement(ColumnNode).SetAttribute('WIDTH',
UTF8Decode(string(ExportFields.Fields[ItemCounter].Field.Size)));
end;
Is dead wrong. It passes on 32-bit (but generating wrong data), but
fails to compile on 64-bit.
Hmmm, hadn't thought about size. (And size obviously matters here ;)
Just to make sure I understand correctly: in a string field, Field.Size
indicates the number of characters that can be stored in a field, while
Field.DataSize indicates the number of bytes, right?
Yes.
Complication is that e.g. Access expect character size for their size
specification. Delphi Clientdataset will probably require datasize.
I don't think so, but I'm not sure. I would have to test that.
Thanks, I'll look into it.
The compiler has a warning for this, so checking your warnings while
compiling for 32-bit may also be a good idea.
Michael.
New plans:
1. Expand test coverage: additional datatypes, fixed string width fully
filled with East Asian characters.
Use the output of this coverage as baseline to verify code commits still
deliver the proper export.
2. Incorporate fixes, e.g. those mentioned by Ludo Brands. Please keep
those reports coming ;)
3. Clean up code (needless class-level variables), look into possibility
of splitting entire procedures according to export format, instead of
multiple case...of statements inside a procedure body.
I would appreciate that one. I think with some refactoring, the code could
be made much simpler.
I'll keep a Mercurial repository on bitbucket to coordinate with others
and upload a new patch when done.
Let me know when you're ready for a new patch :-)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On 28-7-2011 6:34, Reinier Olislagers wrote: On 27-7-2011 20:49, Ludo Brands wrote: Some problems with Delphi Clientdataset: -Delphi has the dfXMLUTF8 and dfXML format for exporting data but no way to specify this for reading. The difference is in the first line: encoding=UTF-8. Was afraid of that. FCL XML has no support for specifying encoding. I might need to add a bug and a hackish workaround (if possible, opening the XML file we just created and rewriting the first line) Submitted in FPC bugtracker, issue 19827 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
On Wed, 27 Jul 2011, Reinier Olislagers wrote: Hi list ( Michael Van Canneyt ;), Earlier I announced I was writing another XML export module for FCL-DB. After some interesting hours with Excel, Access, .Net and FreePascal, and thanks to Ludo Brands for testing and bugfixes, it seems the work is done. What is it: an FCL-DB export module that can export in various Unicode XML formats: Access/SQL Server, ADO.Net and Excel. The ADO.Net format is quite basic and might be suited for importing back into FreePascal (I'd suggest adding an FPC namespace with datatypes though, because you can't map FPC datatypes 1:1 with .Net datatypes). Suggestions for additional XML export formats are welcome. Well, I have 2 on my wishlist: 1. The format used by Delphi's TClientDataset ? 2. Atom feeds as used by Google. Feel free to take a shot at it :-) Is it tested: yep: export and import on Access XP, import by ADO.Net, import on Excel XP. Earlier versions of the code were tested with import on Access 2010. The code comes with some simple tests (basically testing if the various export formats actually finish without error) and a readme. I think it is stable enough to include in FPC 2.5.1 for more wide scale use and testing. I've uploaded it to bug 19790: files: 20110727_XMLXSDExport_Code.zip: the code, patch for fpc makefile I've annotated the code with Lazarus todo entries to indicate possible improvements/tests. 20110727_XMLXSDExport_Tests.zip: the test code. Note: I haven't patched any makefiles, don't know if that's necessary Could an administrator remove the rest of the files as they are older, superfluous and will confuse users? Thanks. Hope it can be applied, of course I'm available for any necessary changes/improvements, I will look at it tonight, together with your CSV dataset improvements. I'll also adapt the lazarus data desktop to include the new export format. In each case, thank you very much for your efforts; It's really hugely appreciated ! Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
On 27-7-2011 12:26, michael.vancann...@wisa.be wrote: On Wed, 27 Jul 2011, Reinier Olislagers wrote: Suggestions for additional XML export formats are welcome. Well, I have 2 on my wishlist: 1. The format used by Delphi's TClientDataset ? Ok, I've used that one once... so I could give it a shot... 2. Atom feeds as used by Google. Feel free to take a shot at it :-) Do you mean the 0.3 format - https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29#Atom_0.3_and_adoption_by_Google or the 1.0 format? Would of course be interesting to map fields to atom entries - I suppose you could use fields that have the same names such as title, subtitle, id, updated - but there are hierarchical elements: link, subelements inside an entry... that would require multiple datasets in FPC (something like the ADO.Net dataset concept that includes the possibility of multiple tables, including parent/child relationships... Scary. Just to make sure I understand correctly - I'm still a Lazarus newbie - there isn't support for such a parent/child tables kind of dataset (group) in FPC/Lazarus/Delphi, is there? (I did see an ftDataSet field type so maybe that could be a clue?) Would you perhaps have an example of a dataset/table and the resulting XML you want to see? I will look at it tonight, together with your CSV dataset improvements. I'll also adapt the lazarus data desktop to include the new export format. In each case, thank you very much for your efforts; It's really hugely appreciated ! Michael. Great, thanks ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
2. Atom feeds as used by Google. Feel free to take a shot at it :-) Do you mean the 0.3 format - https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29#Atom_0.3 AFAIK data exports are all general purpose, ie they represent the data, and evenually their schema, as precise as possible without any knowledge of the contents. Atoms are specific and need understanding of the contents. Hence Reiniers remarks about mapping fields, etc. I understand the interest one can have being able to export this format but, IMHO, that doesn't belong in a data export library. Nice try though :-) Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
On Wed, 27 Jul 2011, Ludo Brands wrote: 2. Atom feeds as used by Google. Feel free to take a shot at it :-) Do you mean the 0.3 format - https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29#Atom_0.3 AFAIK data exports are all general purpose, ie they represent the data, and evenually their schema, as precise as possible without any knowledge of the contents. Atoms are specific and need understanding of the contents. Hence Reiniers remarks about mapping fields, etc. I understand the interest one can have being able to export this format but, IMHO, that doesn't belong in a data export library. Nice try though :-) Data is just data to me, however it is represented :-) For me, atom feeds are just an 'extra' simple XML mapping: FieldName - NodePath Possibly with a grouping concept. Still, I will need the Atom export, so eventually it will be made. In fact, Inoussa Ouedraogo (hope I spelled that correct) made a complete SDO implementation in FPC which should be powerful enough to able to handle this. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
On 27.07.2011 14:05, michael.vancann...@wisa.be wrote: On Wed, 27 Jul 2011, Ludo Brands wrote: 2. Atom feeds as used by Google. Feel free to take a shot at it :-) Do you mean the 0.3 format - https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29#Atom_0.3 AFAIK data exports are all general purpose, ie they represent the data, and evenually their schema, as precise as possible without any knowledge of the contents. Atoms are specific and need understanding of the contents. Hence Reiniers remarks about mapping fields, etc. I understand the interest one can have being able to export this format but, IMHO, that doesn't belong in a data export library. Nice try though :-) Data is just data to me, however it is represented :-) For me, atom feeds are just an 'extra' simple XML mapping: FieldName - NodePath Possibly with a grouping concept. Still, I will need the Atom export, so eventually it will be made. In fact, Inoussa Ouedraogo (hope I spelled that correct) made a complete SDO implementation in FPC which should be powerful enough to able to handle this. Is this SDO Service Data Objects which I quickly googled? If so, what exactly is it, what are its strengths? If not: what is SDO then? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
On Wed, 27 Jul 2011, Sven Barth wrote: On 27.07.2011 14:05, michael.vancann...@wisa.be wrote: On Wed, 27 Jul 2011, Ludo Brands wrote: 2. Atom feeds as used by Google. Feel free to take a shot at it :-) Do you mean the 0.3 format - https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29#Atom_0.3 AFAIK data exports are all general purpose, ie they represent the data, and evenually their schema, as precise as possible without any knowledge of the contents. Atoms are specific and need understanding of the contents. Hence Reiniers remarks about mapping fields, etc. I understand the interest one can have being able to export this format but, IMHO, that doesn't belong in a data export library. Nice try though :-) Data is just data to me, however it is represented :-) For me, atom feeds are just an 'extra' simple XML mapping: FieldName - NodePath Possibly with a grouping concept. Still, I will need the Atom export, so eventually it will be made. In fact, Inoussa Ouedraogo (hope I spelled that correct) made a complete SDO implementation in FPC which should be powerful enough to able to handle this. Is this SDO Service Data Objects which I quickly googled? It is. If so, what exactly is it, what are its strengths? A uniform way to access all kinds of data. You can see it as an alternative to TDataset and friends. It's quite powerful, really. Inoussa has made some nice sample applications. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
On 27.07.2011 19:24, Michael Van Canneyt wrote: On Wed, 27 Jul 2011, Sven Barth wrote: On 27.07.2011 14:05, michael.vancann...@wisa.be wrote: On Wed, 27 Jul 2011, Ludo Brands wrote: 2. Atom feeds as used by Google. Feel free to take a shot at it :-) Do you mean the 0.3 format - https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29#Atom_0.3 AFAIK data exports are all general purpose, ie they represent the data, and evenually their schema, as precise as possible without any knowledge of the contents. Atoms are specific and need understanding of the contents. Hence Reiniers remarks about mapping fields, etc. I understand the interest one can have being able to export this format but, IMHO, that doesn't belong in a data export library. Nice try though :-) Data is just data to me, however it is represented :-) For me, atom feeds are just an 'extra' simple XML mapping: FieldName - NodePath Possibly with a grouping concept. Still, I will need the Atom export, so eventually it will be made. In fact, Inoussa Ouedraogo (hope I spelled that correct) made a complete SDO implementation in FPC which should be powerful enough to able to handle this. Is this SDO Service Data Objects which I quickly googled? It is. If so, what exactly is it, what are its strengths? A uniform way to access all kinds of data. You can see it as an alternative to TDataset and friends. It's quite powerful, really. Inoussa has made some nice sample applications. Now you've made me curious... where is it available? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
On Wed, 27 Jul 2011, Sven Barth wrote: On 27.07.2011 19:24, Michael Van Canneyt wrote: On Wed, 27 Jul 2011, Sven Barth wrote: On 27.07.2011 14:05, michael.vancann...@wisa.be wrote: On Wed, 27 Jul 2011, Ludo Brands wrote: 2. Atom feeds as used by Google. Feel free to take a shot at it :-) Do you mean the 0.3 format - https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29#Atom_0.3 AFAIK data exports are all general purpose, ie they represent the data, and evenually their schema, as precise as possible without any knowledge of the contents. Atoms are specific and need understanding of the contents. Hence Reiniers remarks about mapping fields, etc. I understand the interest one can have being able to export this format but, IMHO, that doesn't belong in a data export library. Nice try though :-) Data is just data to me, however it is represented :-) For me, atom feeds are just an 'extra' simple XML mapping: FieldName - NodePath Possibly with a grouping concept. Still, I will need the Atom export, so eventually it will be made. In fact, Inoussa Ouedraogo (hope I spelled that correct) made a complete SDO implementation in FPC which should be powerful enough to able to handle this. Is this SDO Service Data Objects which I quickly googled? It is. If so, what exactly is it, what are its strengths? A uniform way to access all kinds of data. You can see it as an alternative to TDataset and friends. It's quite powerful, really. Inoussa has made some nice sample applications. Now you've made me curious... where is it available? You should ask Inoussa. I don't think he has published it yet. I have a first version available here, but I'm not sure if I can distribute it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
Update: includes first stab at Delphi Clientdataset. Please
test with various datatypes as I haven't been able to map all
of them...
Some problems with Delphi Clientdataset:
-METADATA comes after ROWDATA and Delphi 2006 complains about missing
metadata. Inverting the 2 blocks solves the problem. Moved the METADATA
block from 2555 to 2462
- datetime and timestamp are missing time part as mentioned in the comments.
Formatdatetime('mmddThh:nn:ss', EF.Field.AsDateTime) solves that.
- bcd: invalid field type
- the mysql text types (tinytext,text, longtext, etc) are exported as
bin.hex with subtype binary. Perhaps a problem in the mysql code.
- when a string field contains the character, the row is not imported but
the previous one is duplicated.
-Delphi has the dfXMLUTF8 and dfXML format for exporting data but no way to
specify this for reading. The difference is in the first line:
encoding=UTF-8.
I'll investigate further and let you know by tomorrow.
Ludo
Ludo
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On Wed, 27 Jul 2011, Reinier Olislagers wrote:
Update: includes first stab at Delphi Clientdataset. Please test with
various datatypes as I haven't been able to map all of them...
I added your implementation to SVN.
But you may want to check your implementation on 64-bit prior to submitting.
Code like
ftWideString: //fixed length or at least max length string
begin
TDOMElement(ColumnNode).SetAttribute('fieldtype', 'string');
TDOMElement(ColumnNode).SetAttribute('WIDTH',
UTF8Decode(string(ExportFields.Fields[ItemCounter].Field.Size)));
end;
Is dead wrong. It passes on 32-bit (but generating wrong data),
but fails to compile on 64-bit.
The compiler has a warning for this, so checking your warnings while
compiling for 32-bit may also be a good idea.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
On 27.07.2011 20:48, michael.vancann...@wisa.be wrote: On Wed, 27 Jul 2011, Sven Barth wrote: On 27.07.2011 19:24, Michael Van Canneyt wrote: On Wed, 27 Jul 2011, Sven Barth wrote: On 27.07.2011 14:05, michael.vancann...@wisa.be wrote: On Wed, 27 Jul 2011, Ludo Brands wrote: 2. Atom feeds as used by Google. Feel free to take a shot at it :-) Do you mean the 0.3 format - https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29#Atom_0.3 AFAIK data exports are all general purpose, ie they represent the data, and evenually their schema, as precise as possible without any knowledge of the contents. Atoms are specific and need understanding of the contents. Hence Reiniers remarks about mapping fields, etc. I understand the interest one can have being able to export this format but, IMHO, that doesn't belong in a data export library. Nice try though :-) Data is just data to me, however it is represented :-) For me, atom feeds are just an 'extra' simple XML mapping: FieldName - NodePath Possibly with a grouping concept. Still, I will need the Atom export, so eventually it will be made. In fact, Inoussa Ouedraogo (hope I spelled that correct) made a complete SDO implementation in FPC which should be powerful enough to able to handle this. Is this SDO Service Data Objects which I quickly googled? It is. If so, what exactly is it, what are its strengths? A uniform way to access all kinds of data. You can see it as an alternative to TDataset and friends. It's quite powerful, really. Inoussa has made some nice sample applications. Now you've made me curious... where is it available? You should ask Inoussa. I don't think he has published it yet. I have a first version available here, but I'm not sure if I can distribute it. Then I'll wait until it's ready. I'll contain my curiosity till then ^^ Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790
Now you've made me curious... where is it available? You should ask Inoussa. I don't think he has published it yet. I have a first version available here, but I'm not sure if I can distribute it. Then I'll wait until it's ready. I'll contain my curiosity till then ^^ I just sent the live sources to both of you in private message. Reminder to my self : publish the code, publish the code, publish the code :-) -- Inoussa O. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On 27-7-2011 20:49, Ludo Brands wrote:
Update: includes first stab at Delphi Clientdataset. Please
test with various datatypes as I haven't been able to map all
of them...
Some problems with Delphi Clientdataset:
-METADATA comes after ROWDATA and Delphi 2006 complains about missing
metadata. Inverting the 2 blocks solves the problem. Moved the METADATA
block from 2555 to 2462
I'll look into that.
- datetime and timestamp are missing time part as mentioned in the comments.
Formatdatetime('mmddThh:nn:ss', EF.Field.AsDateTime) solves that.
I'll look into that.
- bcd: invalid field type
Ok, what field type do we need ;) I'll wait for your further investigations.
- the mysql text types (tinytext,text, longtext, etc) are exported as
bin.hex with subtype binary. Perhaps a problem in the mysql code.
Ok.
Am looking at test coverage, might be a good idea for medium term to use
current sqldb testing framework so we can use eg Firebird employee
sample database or an mysql database.
For now, I'll wait for your further investigations.
- when a string field contains the character, the row is not imported but
the previous one is duplicated.
Strange, shouldn't this be handled by the XML export code?
-Delphi has the dfXMLUTF8 and dfXML format for exporting data but no way to
specify this for reading. The difference is in the first line:
encoding=UTF-8.
Was afraid of that. FCL XML has no support for specifying encoding. I
might need to add a bug and a hackish workaround (if possible, opening
the XML file we just created and rewriting the first line)
I'll investigate further and let you know by tomorrow.
Ludo
Hi Ludo,
https://bitbucket.org/reiniero/fpc_laz_patch_playground/issue/2/delphi-createdataset-issues
Thanks, looking forward to your results...
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset
On 27-7-2011 20:52, michael.vancann...@wisa.be wrote:
On Wed, 27 Jul 2011, Reinier Olislagers wrote:
Update: includes first stab at Delphi Clientdataset. Please test with
various datatypes as I haven't been able to map all of them...
I added your implementation to SVN.
Thanks, Michael.
I noticed your remark on a failing conversion of a longint to a string -
that code wouldn't have worked. Obviously a priority to increase the
test coverage.
But you may want to check your implementation on 64-bit prior to
submitting.
I will compile test on Linux x64 before submitting an upgrade
Code like
ftWideString: //fixed length or at least max length string
begin
TDOMElement(ColumnNode).SetAttribute('fieldtype', 'string');
TDOMElement(ColumnNode).SetAttribute('WIDTH',
UTF8Decode(string(ExportFields.Fields[ItemCounter].Field.Size)));
end;
Is dead wrong. It passes on 32-bit (but generating wrong data), but
fails to compile on 64-bit.
Hmmm, hadn't thought about size. (And size obviously matters here ;)
Just to make sure I understand correctly: in a string field, Field.Size
indicates the number of characters that can be stored in a field, while
Field.DataSize indicates the number of bytes, right?
Complication is that e.g. Access expect character size for their size
specification. Delphi Clientdataset will probably require datasize.
Thanks, I'll look into it.
The compiler has a warning for this, so checking your warnings while
compiling for 32-bit may also be a good idea.
Michael.
New plans:
1. Expand test coverage: additional datatypes, fixed string width fully
filled with East Asian characters.
Use the output of this coverage as baseline to verify code commits still
deliver the proper export.
2. Incorporate fixes, e.g. those mentioned by Ludo Brands. Please keep
those reports coming ;)
3. Clean up code (needless class-level variables), look into possibility
of splitting entire procedures according to export format, instead of
multiple case...of statements inside a procedure body.
I'll keep a Mercurial repository on bitbucket to coordinate with others
and upload a new patch when done.
Thanks,
Reinier
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
