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

Christian Stimming stimming at tuhh.de
Tue Dec 12 03:47:10 EST 2006

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=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?

Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the gnucash-devel mailing list