Re: Sorting out QSF import and export
Derek Atkins writes:
> David Goodenough writes:
>> Where is the GNC XML format defined? I have some ideas that I have
>> used elsewhere to fix the GUID problem.
>
> It's defined in the sources. see src/business/business-core/xml
There's a non-normative post-hoc schema in ,
as well.
>>> The existing code was pretty sophisticated in that you could plug
>>> in various matching rules per object and such. But it was very buggy,
>>> and it's been a long time since I've looked at it.
>>
>> Are you talking about the QSF code, or the other import/export code?
>
> QSF.. in the merge code. dialog-merge? druid-merge? Something like that.
, .
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
pgpNe5CLwuTDK.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Sorting out QSF import and export
David Goodenough writes: >> > Domain-specific import/export formats and import/export logic are going >> > to be far easier to implement, debug and use. >> >> Maybe.. Keep in mind that the information in an import object is not >> necessarily the same used internally. Yes, one COULD use the GNC XML >> object formats for import/export, but you'd still need to recode >> the I/O to handle import objects differently (e.g. lack of a GUID). > > Where is the GNC XML format defined? I have some ideas that I have > used elsewhere to fix the GUID problem. It's defined in the sources. see src/business/business-core/xml What ideas do you have to fix the GUID problem? GnuCash requires some GUID references between objects which could cause problems when you just randomly try to create the XML by hand. >> > Hopefully, you can find something to leverage in the existing (generic, >> > not QIF-specific) importer/exporter, but for things like Customers and >> > Vendors where there's not an src/engine/Account to match against, I'm >> > not sure if the existing code will be trivially adaptable; those Vendors >> > and Customers are different data-sources for matching purposes. > > Well there can be a match, it might not be by ID, but it might by some > other field match. Of course; an import match would be by Company Name, or maybe address. >> The existing code was pretty sophisticated in that you could plug >> in various matching rules per object and such. But it was very buggy, >> and it's been a long time since I've looked at it. > > Are you talking about the QSF code, or the other import/export code? QSF.. in the merge code. dialog-merge? druid-merge? Something like that. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Sorting out QSF import and export
On Tuesday 09 June 2009, Derek Atkins wrote: > Josh Sled writes: > > David Goodenough writes: > >> So the question is, which way to go. Should I simply work on the old > >> QSF code and get it to work, and then add selection to it and matching, > >> or should I look at the new framework and rewrite the QSF code to work > >> there? > > > > QSF is a bad idea. Please don't propagate it. I am not wedded to QSF, I am wedded to an XML import/export which can then be trasformed using XSLT into whatever other XML format might be required. > > This is where Josh and I disagree.. I don't believe it's completely > a bad idea, but I believe the what's there is poorly done. The concept > of a generic XML that can encode and parse generic objects is a good > idea IMHO. But what's there is... limited. I agree with this. > > > Domain-specific import/export formats and import/export logic are going > > to be far easier to implement, debug and use. > > Maybe.. Keep in mind that the information in an import object is not > necessarily the same used internally. Yes, one COULD use the GNC XML > object formats for import/export, but you'd still need to recode > the I/O to handle import objects differently (e.g. lack of a GUID). Where is the GNC XML format defined? I have some ideas that I have used elsewhere to fix the GUID problem. > > > Hopefully, you can find something to leverage in the existing (generic, > > not QIF-specific) importer/exporter, but for things like Customers and > > Vendors where there's not an src/engine/Account to match against, I'm > > not sure if the existing code will be trivially adaptable; those Vendors > > and Customers are different data-sources for matching purposes. Well there can be a match, it might not be by ID, but it might by some other field match. > > I doubt that any of the existing importer code will help with > any of the business objects. > > > Note that I'm speaking at a high-level, I'd be happy if you found the > > code was more sophisticated than I'm thinking. > > The existing code was pretty sophisticated in that you could plug > in various matching rules per object and such. But it was very buggy, > and it's been a long time since I've looked at it. Are you talking about the QSF code, or the other import/export code? > > David, you should ignore external QOF. It went off in a completely > different direction and at this point I don't think it would be trivial > to do a merge. And we're not at all interested in a merge because > frankly we've put a bunch of bug-fixes into the code and the last time > we had a merge those bug fixes were lost. Fine > > As for pulling up their QSF -- that COULD be an option, but I don't > think that the majority of work is in the QSF backend but rather in the > GUI frontend. If there is a viable alternative I am happy to go with it. David > > There *is* QSF Import UI, but it's just not hooked into the Menus. > Take a look at ./src/gnome/gnc-plugin-basic-commands.c and in particular > the macro QSF_IMPORT_WORKS > > -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Sorting out QSF import and export
Josh Sled writes: > David Goodenough writes: >> So the question is, which way to go. Should I simply work on the old QSF >> code and get it to work, and then add selection to it and matching, or should >> I look at the new framework and rewrite the QSF code to work there? > > QSF is a bad idea. Please don't propagate it. This is where Josh and I disagree.. I don't believe it's completely a bad idea, but I believe the what's there is poorly done. The concept of a generic XML that can encode and parse generic objects is a good idea IMHO. But what's there is... limited. > Domain-specific import/export formats and import/export logic are going > to be far easier to implement, debug and use. Maybe.. Keep in mind that the information in an import object is not necessarily the same used internally. Yes, one COULD use the GNC XML object formats for import/export, but you'd still need to recode the I/O to handle import objects differently (e.g. lack of a GUID). > Hopefully, you can find something to leverage in the existing (generic, > not QIF-specific) importer/exporter, but for things like Customers and > Vendors where there's not an src/engine/Account to match against, I'm > not sure if the existing code will be trivially adaptable; those Vendors > and Customers are different data-sources for matching purposes. I doubt that any of the existing importer code will help with any of the business objects. > Note that I'm speaking at a high-level, I'd be happy if you found the > code was more sophisticated than I'm thinking. The existing code was pretty sophisticated in that you could plug in various matching rules per object and such. But it was very buggy, and it's been a long time since I've looked at it. David, you should ignore external QOF. It went off in a completely different direction and at this point I don't think it would be trivial to do a merge. And we're not at all interested in a merge because frankly we've put a bunch of bug-fixes into the code and the last time we had a merge those bug fixes were lost. As for pulling up their QSF -- that COULD be an option, but I don't think that the majority of work is in the QSF backend but rather in the GUI frontend. There *is* QSF Import UI, but it's just not hooked into the Menus. Take a look at ./src/gnome/gnc-plugin-basic-commands.c and in particular the macro QSF_IMPORT_WORKS -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Sorting out QSF import and export
David Goodenough writes:
> So the question is, which way to go. Should I simply work on the old QSF
> code and get it to work, and then add selection to it and matching, or should
> I look at the new framework and rewrite the QSF code to work there?
QSF is a bad idea. Please don't propagate it.
Domain-specific import/export formats and import/export logic are going
to be far easier to implement, debug and use.
Hopefully, you can find something to leverage in the existing (generic,
not QIF-specific) importer/exporter, but for things like Customers and
Vendors where there's not an src/engine/Account to match against, I'm
not sure if the existing code will be trivially adaptable; those Vendors
and Customers are different data-sources for matching purposes.
Note that I'm speaking at a high-level, I'd be happy if you found the
code was more sophisticated than I'm thinking.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
pgp4PPD0rfnHX.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Sorting out QSF import and export
I sent a couple of questions to the user list recently about the import and export of data (customers and invoices are of particular interest to me) and it became obvious that the only provided route is QSF, but that QSF import and export support is buggy and un-maintained and quite likely to get removed. Digging further I found that QOF appears to exist in two versions now, the one that GnuCash uses, and the one everyone else uses. I gather that there are differences which would make it difficult for GnuCash to move to the latest version. They also seem to have gone a different route for SQL support, but that is a different matter. The QSF support that is present in GnuCash seems to be export only (at least that is all that is visible on the menusa), and currently it does nothing (at least when I try to use it on 2.3.1). It also appears that all you can do is export all the customers, or all the invoices etc - no selection. There would also appear to be a separate import and export framework developing around QIF and OFX, but again this seems incomplete in that I can only find ways of importing data, no export. This however does seem to have matching code for tying the incomming data into the relevant accounts on GnuCash. So the question is, which way to go. Should I simply work on the old QSF code and get it to work, and then add selection to it and matching, or should I look at the new framework and rewrite the QSF code to work there? Any suggestions? David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
