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

[John Ralls]

> On Jan 23, 2016, at 2:37 PM, Jesse Olmer <jesse at wickedgoodtimes.com> wrote:
> 
> I'm tackling this bug as my first contribution to the project and have
> a few technical questions.
> 
> To track pending matches within the current import process there are
> two main possibilities that come to mind. I'm almost sure the first is
> a bad practice, but I don't want to make assumptions about the general
> system architecture and use patterns. The first is that it appears the
> Split on the GNCImportMatchInfo objects are somewhat persistent (I
> didn't jump into the bowels of the query system, but I didn't see them
> being freed anywhere in import-export). Therefore, I could piggy back
> on the Split to store information about whether it was a pending match
> for one of the imported transactions. This seems like a bad idea since
> it breaks encapsulation of the feature, plus if these are truly
> persistent throughout the application it just creates a mess and
> cleanup issues.
> 
> The second route (and the one I've already started on) is to have a
> new object which ref counts pending matches (essentially, a map of
> match info's to their ref count and some metadata for display). An
> instance of this object lives in GNCImportMainMatcher and is passed to
> the GNCImportMatchPicker providing fast lookup for each match. If this
> doesn't pass the sniff test please let me know.
> 
> Since this is brand new, mostly self-contained code, I'm going the C++
> route with it. I'm curious what the state is of the recommended Google
> Test integration. The Testing page on the wiki has a blank section for
> this, and I wasn't able to locate any other examples in maint. I see
> several uses in master, so maybe this isn't something that has been
> merged to maint? If that's the case I can test through the C interface
> to the C++ class as it's a fairly trivial object (or I can nix the C++
> idea altogether if that's preferred).
> 
> Lastly, I've read the wiki on translations but I didn't see anything
> about a preferred process for getting new strings translated. Is it
> good enough to add the _() as documented and someone will pick it up
> eventually, is a bug preferred, or something else?

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?

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.

Yes, just mark the new strings with _() and they'll be picked up by translators. Few if any translators look at bugs so a bug report is unlikely to do any good.

Regards,
John Ralls