Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2011-07

Patch: new XML export for FCL-DB ready for inclusion, issue 19790

11 messages · 6 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Reinier Olislagers

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.

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,

Thanks for all the help,
Reinier

Reply by email

Unknown author
to Reinier Olislagers
Reinier Olislagers wrote 15 lines
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 :-)

Show quoted text 24 lines
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.

Reply by email

Reinier Olislagers
to Unknown author
Show quoted text 6 lines
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?

Show quoted text 7 lines
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

Reply by email

Ludo Brands
to Reinier Olislagers
Show quoted text 5 lines
> 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

Reply by email

Unknown author
to Ludo Brands
Ludo Brands wrote 13 lines
>> 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.

Reply by email

Sven Barth
to Unknown author
Show quoted text 34 lines
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

Reply by email

Michael Van Canneyt
to Sven Barth
Sven Barth wrote 38 lines
On 27.07.2011 14:05, 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.

Reply by email

Sven Barth
to Michael Van Canneyt
Michael Van Canneyt wrote 54 lines
On Wed, 27 Jul 2011, Sven Barth wrote: > On 27.07.2011 14:05, 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

Reply by email

Unknown author
to Sven Barth
Sven Barth wrote 57 lines
On 27.07.2011 19:24, Michael Van Canneyt wrote: > > > On Wed, 27 Jul 2011, Sven Barth wrote: > >> On 27.07.2011 14:05, 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.

Reply by email

Sven Barth
to Unknown author
Show quoted text 68 lines
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, 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

Reply by email

Inoussa OUEDRAOGO
to Sven Barth
Show quoted text 8 lines
>> 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.

Reply by email