Import transactions change proposal

Greg Stark gsstark at
Sun Feb 9 15:17:39 CST 2003

Derek Atkins <warlord at MIT.EDU> writes:

> Greg Stark <gsstark at MIT.EDU> writes:
> > Derek Atkins <warlord at MIT.EDU> writes:
> > 
> > > The problem is that data import is "lossy", you don't necessarily have
> > > all the import information in the GNC Transaction.  For example, you
> > > lose the QIF Category name, but you DEFINITELY want to be able to map
> > > from QIF Category to GNC Account.  
> > 
> > Well, my first reaction is that importing shouldn't be lossy. Having lossy
> > steps closes options such as being able to show the user where a transaction
> > came from and what the information the bank presented was. I could see that
> > being useful in a dispute with a bank or debugging problems after the fact.
> Argubly it has to be, considering the GNC format is very different
> from the QIF format, which is very different than OFX or HBCI...  So
> by definition you're going to have SOME loss.  

Well what I meant was that the transaction should keep a copy of the original
raw data it was imported from. double clicking to view a transaction detail
should show the user what the raw data was.

> Perhaps, but there is a good reason for this.  There is call for
> actually using separate data stores for different periods, for example
> one XML data-file per year.  The reason is that XML is LARGE, and you
> necessarily need to read/parse a complete XML document.  After several
> years your data file can get to be tens or maybe even hundreds of
> megabytes -- why force users to load all that extraneous data?

I guess I'm not impressed by XML. It feels weird to be driving major design
decisions from the fact that XML is bloated and cannot be parsed


More information about the gnucash-devel mailing list