Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

[John Ralls]

> On Jan 23, 2016, at 5:18 PM, Jesse Olmer <jesse at wickedgoodtimes.com> wrote:
> 
>> Why not just add a gboolean "used" attribute to _matchinfo, set it true when the corresponding transaction is used in a match and exclude the instance from the match_list if its used attribute is true?
> 
> I think there's two problems with that. _matchinfo instances are not
> shared across multiple transactions, they're created in
> split_find_match during the transaction initialization, so we can't
> use it to track whether any other instances have it as a pending
> match. The second problem is that whatever common data location is
> used needs to be able to ref count because multiple transactions could
> have the same best match based on the heuristic. A simple bool causes
> a problem when the user goes into the match picker for one of these
> transactions and changes it to a different item - we can't just set to
> false because it could still be a match for another transaction.
> 
> Additionally, I think it's probably going to be useful to be able to
> indicate to the user whether the pending match is an automatic or
> manual selection, so having that reference back to the
> _transactioninfo(s) or pulling that data along in a new object would
> be necessary.

Ah, I see that match_info is private to transactioninfo, so the list of already-matched existing transaction has to be maintained outside of matchinfo, and the transactioninfos are all loaded at once at the beginning, so that's the wrong list.
The right one is the GtkListStore *store in import-match-picker.c. How about keeping a GHashTable of GUIDs of transactions or splits, which ever is easier, that have already been matched and filter out adding any transactions whose GUIDs are in the GHashTable? There's already a guid_hashtable_new() for you in src/libqof/qof/guid.h.

BTW, you're right about Splits and Transactions being persistent. You don't want to piggy back onto them.

> 
>> 
>> C++ is for master, not maint. There's google test example code src/libqof/qof/test/gtest*. We use the glib test framework for new unit tests on C code in maint.
> 
> Got it. All of the work for the primary part of the bug was done in C,
> so I could always split it up into two patches (one for each branch).
> I'll decide once I'm a bit closer to the final solution.

Since import-export hasn't been converted yet, it's better to just write your patch in C for maint and let it get converted with the rest of the module.

Regards,
John Ralls