> On Jan 6, 2020, at 8:55 AM, John Ralls wrote:
>
>
>
>> On Jan 5, 2020, at 11:14 PM, Mike Alexander wrote:
>>
>> On 5 Jan 2020, at 23:27, John Ralls wrote:
>>
>> I want you to code review and test the PR when I finish. ;-)
>>
>> The online_id comes from from the import source,
> On Jan 5, 2020, at 11:14 PM, Mike Alexander wrote:
>
> On 5 Jan 2020, at 23:27, John Ralls wrote:
>
> I want you to code review and test the PR when I finish. ;-)
>
> The online_id comes from from the import source, AQBanking in this particular
> case--and we must be more careful because
On 5 Jan 2020, at 23:27, John Ralls wrote:
I want you to code review and test the PR when I finish. ;-)
The online_id comes from from the import source, AQBanking in this
particular case--and we must be more careful because the code in
question applies to all of the importers except QIF--and
> On Jan 5, 2020, at 7:44 PM, Mike Alexander wrote:
>
> On 5 Jan 2020, at 19:46, John Ralls wrote:
>
> Complexity is not a valid reason to reject a solution to a complex problem
> unless there's a simpler solution that solves it *just as well*. Hackish
> solutions--and I'm just as guilty
On 5 Jan 2020, at 19:46, John Ralls wrote:
Complexity is not a valid reason to reject a solution to a complex
problem unless there's a simpler solution that solves it *just as
well*. Hackish solutions--and I'm just as guilty on that front as I
wrote the strncmp hack--are far more likely to
> On Jan 5, 2020, at 2:01 PM, Christian Stimming wrote:
>
> Am Sonntag, 5. Januar 2020, 22:39:58 CET schrieb Mike Alexander:
>> I agree that running the search twice is probably ok. However, John
>> raises another point which seems relevant. What if there is more than
>> one partial match?
Am Sonntag, 5. Januar 2020, 22:39:58 CET schrieb Mike Alexander:
> I agree that running the search twice is probably ok. However, John
> raises another point which seems relevant. What if there is more than
> one partial match? Right now it returns the first one. It would seem
> better to punt
I agree that running the search twice is probably ok. However, John
raises another point which seems relevant. What if there is more than
one partial match? Right now it returns the first one. It would seem
better to punt if there is no full match and more than one partial
match.
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
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
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
> On Jan 5, 2020, at 12:40 AM, Mike Alexander 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
>
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
13 matches
Mail list logo
