engine objects vs. SX or invoices (was: GDA: A few questions)
warlord at MIT.EDU
Tue Dec 12 09:54:18 EST 2006
Christian Stimming <stimming at tuhh.de> writes:
> 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?
I think it might solve it; we'd have to add one more flag to the
transaction object, a "transaction type" (although that term is
already taken for something else so I think we'll need to think of
something else, maybe "txn model" or something... Every transaction
would have to get this set to something (although we could make it so
that standard txns are empty).
Then we'd have to change EVERY query to explicitly look for a specific
type: NORMAL_TXN, SX_TXN, IMPORT_TXN, etc. It would require touching
every place we make a query..
It's sort of like what the qofQuerySearchFor() API is for, but this
would be subtyping on Split (or Transaction)..
HOWEVER, I think there's another issue here.. When you're doing a
large import and you create new accounts as part of the import, if you
then cancel the import process these new accounts don't get backed
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
warlord at MIT.EDU PGP key available
More information about the gnucash-devel