engine objects vs. SX or invoices (was: GDA: A few questions)

Chris Shoemaker c.shoemaker at cox.net
Tue Dec 12 09:52:20 EST 2006

On Tue, Dec 12, 2006 at 09:47:10AM +0100, Christian Stimming wrote:
> Hash: SHA1
> Chris Shoemaker schrieb:
> >>> I'm just saying SXs could use the real engine
> >>> objects, just like Invoices.  The only difference is that the engine
> >>> has to learn that "real" SX transactions aren't _that_ real. :)
> >>>
> >> Except Invoices don't either, for the same reason that it's causing
> >> trouble that SXes do -- it complicates all the code when EVERYONE has
> >> to be aware that a foo-object is really part of a bar-object.  Much
> >> easier to just have foo object and bar object and then use KVP GUIDs
> >> to link back and forth.
> > 
> > I can see your point, but I just don't agree that the benefit of not
> > requiring the engine to know how to provide a list of transactions
> > that excludes SXs is greater than the benefit of reusing the
> > data-structures and constraint code.
> There's an interesting additional twist here: We also have "imported
> transactions", i.e. those that have been read by some import-export
> module and are being reviewed by the user in the "generic transaction
> matcher". These took exactly the opposite approach than invoices or SX:
> They are being created as "real" transactions, except that all of them
> are not yet committed until the "generic transaction matcher" dialog is
> finished (at which point in time each "imported transaction" is either
> fully committed or deleted again).
> However, this leads to all sorts of problems with the registers of the
> accounts in question. See
> http://bugzilla.gnome.org/show_bug.cgi?id=150569
> http://bugzilla.gnome.org/show_bug.cgi?id=341076 to name a few. The
> whole generic importer framework would rather need a data type of its
> own as well - OR the "real" objects might have another flag added that
> says "I'm not a real object" to the engine. Chris, would your
> understanding of a potential SX implementation lead to a solution like that?

Yes, in my opinion, imported transactions and template transactions
are both similar enough to "real" transactions to reuse the existing
data structure and code.  This obviously (almost) works for import.  I
would diagnose the problem with import being that it makes no attempt
to distinguish "transactions in the process of being imported" from
real posted transation.

"Import Transactions" can be really created at the beginning of the
import process.  At the end they can be promoted into real
transactions or deleted.  All the while, we wouldn't be keeping
transactions in an open state for long periods, and we wouldn't be
affecting any other views that only care about "real" transaction.

AFAICT, this is really quite a minor change for Import, but I think it
would work.


More information about the gnucash-devel mailing list