Import transactions change proposal

[Greg Stark]

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
incrementally.


--
greg