Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Tue, Dec 12, 2006 at 09:47:10AM +0100, Christian Stimming wrote: -BEGIN PGP SIGNED MESSAGE- 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. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
Christian Stimming [EMAIL PROTECTED] 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=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? 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 out too. Christian -derek -- 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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Mon, 2006-12-11 at 22:06 -0500, Chris Shoemaker wrote: Invoices basically reuse the engine objects. But SXs have: struct TTInfo_s [...] which look suspiciously like a Transaction, and struct TTSplitInfo_s [...] which looks suspiciously like a Split. And then the whole duplicated accounts setup. These structures aren't the actual storage, and are only barely used as runtime representations of Template [Splits and] Transactions. They were sourced from Robert Merkel's work on the SX-from-transaction dialog, and are used (by my hand) in the Mortgage/Loan Druid. In both cases, they're immediately passed to xaccSchedXactionSetTemplateTrans(...), which just converts these degenerate structures into the real template Transactions. Looking back on it, I'd just the calling code to write the template structures directly, though maybe with some convenience functions for readability. The only structures relevant are the Accounts, Transactions and Splits rooted in the Template Account-Group. -- ...jsled http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Tue, Dec 12, 2006 at 10:05:21AM -0500, Josh Sled wrote: On Mon, 2006-12-11 at 22:06 -0500, Chris Shoemaker wrote: Invoices basically reuse the engine objects. But SXs have: struct TTInfo_s [...] which look suspiciously like a Transaction, and struct TTSplitInfo_s [...] which looks suspiciously like a Split. And then the whole duplicated accounts setup. These structures aren't the actual storage, and are only barely used as runtime representations of Template [Splits and] Transactions. They were sourced from Robert Merkel's work on the SX-from-transaction dialog, and are used (by my hand) in the Mortgage/Loan Druid. In both cases, they're immediately passed to xaccSchedXactionSetTemplateTrans(...), which just converts these degenerate structures into the real template Transactions. Looking back on it, I'd just the calling code to write the template structures directly, though maybe with some convenience functions for readability. Ah, thanks for explaining that. That does make a lot more sense. The only structures relevant are the Accounts, Transactions and Splits rooted in the Template Account-Group. So, they already are real Transactions/Splits in an alternate Account hierarchy, where every account must refer to a real account, (named by its guid). So then, my recommendation is just to use real accounts and flag the transactions as templates. Although, this was originally brought up in the context of the register-rewrite, and using the alternate accounts is not a big deal in the register-rewrite. So, this has just been me harping on what I think is a good code improvement. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Tuesday 12 December 2006 09:54, Derek Atkins wrote: 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 out too. That's probably not worth solving. Creating the accounts requires a user intervention anyway, and backing out of the import does not necessarily mean that the user wants or expects all the accounts he manually created to be deleted. -- Benoit Grégoire Technologies Coeus inc. pgpI85tWr1rln.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
Quoting Benoit Grégoire [EMAIL PROTECTED]: On Tuesday 12 December 2006 09:54, Derek Atkins wrote: 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 out too. That's probably not worth solving. Creating the accounts requires a user intervention anyway, and backing out of the import does not necessarily mean that the user wants or expects all the accounts he manually created to be deleted. While I agree it's not worth solving on its own, if we can solve it at the same time as everything else we're working on here then we should. In my opinion, if a user clicks Cancel then EVERYTHING from the import should be canceled, including the new account creation. I'll point out that the way the QIF importer did this was that it created a duplicate account hierarchy for the import and then during the 'finish' it merged everything from the new hierarchy into the original one. But yes, I agree that this problem shouldn't be worked on by itself, I was just pointing out it's one of many ways that the import process isnt atomic. Benoit Grégoire Technologies Coeus inc. -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
