John, I think two passes is fine. We have a O(n) complexity anyway, and O(2n) is not worse than that. So I think running one pass looking for exact match, then (if none was found) looking for the partial match, is fine overall.
Caching partial matches in an extra list with element creation and such IMHO introduces a whole lot of extra complexity that isn't really needed. Just running the search twice should be fine. Regards, Christian Am Sonntag, 5. Januar 2020, 21:09:57 CET schrieb John Ralls: > Mike, > > Two passes would be slow for users with large account trees. Collecting all > of the partial matches would require a full traversal every time and that > wouldn't be much better--and worse in the common case where there's only > one match. > > How about returning immediately on an exact match and stuffing partial > matches onto a list and carrying on until there's an exact match? If > there's no exact match and only one item in the list of partials, return > that, otherwise signal an error somehow. > > Too bad there's no reliable way to traverse just the asset and liability > accounts. > > Regards, > John Ralls > > > On Jan 5, 2020, at 11:20 AM, Mike Alexander <m...@umich.edu> wrote: > > > > Ok, how about changing it to try an exact match first and only try the > > partial match if that fails. If that makes sense I'll fix it tonight. One > > question I have is whether this will do the right thing if I add a new > > security so the parent account exists but the security account doesn't. I > > think it will since the accounts commodity will be wrong. > > > > Mike > > > > On Sun, Jan 5, 2020, 10:01 AM John Ralls <jra...@ceridwen.us> wrote: > > > On Jan 5, 2020, at 12:40 AM, Mike Alexander <m...@umich.edu> wrote: > > > > > > When I tried to do my monthly import of an OFX file containing my > > > TIAA/CREF transactions it failed miserably. I tracked it down to > > > commit 7853f5a2 which changed the matching of online IDs for accounts > > > to only match an initial substring of the required ID. My accounts are > > > structured with a parent account in USD corresponding to a TIAA/CREF > > > account and a sub-account under it for each asset in that account. The > > > online ID for the parent account is something like "TIAA-CREF.ORG > > > C8304GY8 RAM001 101011". The online ID for a sub-account storing an > > > asset is created by appending the asset ID to the parent accounts > > > online ID giving something like "TIAA-CREF.ORG C8304GY8 RAM001 > > > 101011878094101". gnc_import_select_account does a linear search of > > > all accounts in no particular order looking for one where the online ID > > > matches in initial substring of the ID it wants. If it finds the > > > parent account before the sub account it returns that and the process > > > fails since it's the wrong currency. > I don't understand enough about the problem that commit is fixing to know > how to fix it without breaking things. > > Mike, > > > > Rats. > > > > The problem the commit was trying to fix is that AQB 5.99 for FinTS uses a > > raw SWIFT account code that for many German banks includes extra > > characters--often a currency code--on the end. Some banks also pad the > > code with leading zeros and a subsequent commit attempts to resolve that. > > This is https://bugs.gnucash.org/show_bug.cgi?id=797432. > > > > Regards, > > John Ralls > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
