Cannot find text or value inside a split

[John Ralls]

On Feb 16, 2013, at 12:21 AM, Colin Law <clanlaw at googlemail.com> wrote:

> On 16 February 2013 00:58, DonM <dm413-gc at intielectronics.com> wrote:
>> On 2/15/2013 Derek Atkins wrote:
>>> 
>>> On 15 February 2013 19:27, Derek Atkins <warlord at mit.edu> wrote:
>>>> 
>>>> Colin Law <clanlaw at googlemail.com> writes:
>>>> 
>>>>> On 15 February 2013 00:51, John Ralls <jralls at ceridwen.us> wrote:
>>>>>> 
>>>>>> 
>>>>>> On Feb 14, 2013, at 1:55 PM, Colin Law <clanlaw at googlemail.com> wrote:
>>>>>>> 
>>>>>>> ...
>>>>>>> I must be missing something, Derek's query includes split.Account ==
>>>>>>> ThisAccount, but we want to find matches where split.Account !=
>>>>>>> ThisAccount, don't we want instead something like
>>>>>>> Split.ParentTransaction.AnySplit.Account == ThisAccount AND
>>>>>>> Split.Memo == "memo"
>>>>>>> 
>>>>>> 
>>>>>> You're getting tied up in pseudocode.
>>>>>> 
>>>>>> What Derek is trying to convey is "For each split whose account matches
>>>>>> the current account, retrieve from that split's parent transaction every
>>>>>> split and return all of those splits whose memo matches 'memo'".
>>>>>> 
>>>>>> Split.ParentTransaction.AnySplit.Account == ThisAccount is functionally
>>>>>> the same as Split.Account == ThisAccount. That's what Gnucash does now.
>>>>> 
>>>>> 
>>>>> OK, got it.  Isn't AnySplit just a join between the transactions and
>>>>> splits tables?
>>>> 
>>>> 
>>>> Again, you're getting caught up in the pseudocode, and I appologize for
>>>> that.  So let me back up a moment and clear something up, and this a key
>>>> concept:
>>>> 
>>>> An account register does not display Transactions.  It displays Splits.
>>>> 
>>>> Pause for a moment and re-read that sentence.
>>>> 
>>>> * hums for a few minutes to let you re-read that a third and fourth time
>>>> *
>>>> 
>>>> Okay, now that you've grokked that, let's talk about what it means.  A
>>>> transaction is made up of multiple splits.  Each transaction must have
>>>> at least two (a debit and a credit).  Each split has an account, and the
>>>> transaction binds them all together.  However, when you are looking at
>>>> an account register you're really looking at the list of SPLITS that are
>>>> tied to that account.  This works out to a query of:
>>>> 
>>>>   Split.Account == ThisAccount
>>>> 
>>>> When you use the "find" from an account register it's effectively a
>>>> "refine search", which means you take the existing query and apply more
>>>> restrictions to it, based on the functionality of the QofQuery
>>>> Predicates.  So when you refine the search for "Split.Memo == ThisMemo"
>>>> then you get the first query in pseudocode I listed before -- which
>>>> isn't what you want.
>>>> 
>>>> The problem is that there is no "Split.Transaction.AnySplit" Predicate,
>>>> and implementing that would be hard because the query framework has no
>>>> concept of Splits or Transactions.  Unfortunately this is what you are
>>>> asking for, being able to say that you want to find a transaction where
>>>> one split is in "this account", and then the memo of ANY split in that
>>>> split's transaction matches "ThisMemo".  That functionality does not
>>>> exist, and would be challenging to implement in the current QofQuery
>>>> framework.
>>>> 
>>>> So basically this is a long winded way of saying: "I understand what
>>>> you're asking, but it doesn't work that way now.  Morever, it wont work
>>>> like that for a while until we can rework the innards of QofQuery in a
>>>> way that provides better knowledge of underlying object typing, and I
>>>> don't expect that to happen any time soon".
>>> 
>>> 
>>> OK, I see the error in my thinking.  I was forgetting that internally
>>> the software does not directly access the db tables (and there are no
>>> such tables if using the xml backend).  If it did then I think this
>>> would be a trivial problem, but it doesn't so that is that.  For the
>>> moment anyway.
>> 
>> 
>> I'm sorry to prolong this discussion further, but now you have me quite
>> confused.
>> 
>> 
>>>> However, when you are looking at
>>>> 
>>>> an account register you're really looking at the list of SPLITS that are
>>>> tied to that account.
>> 
>> 
>> The register page displays ALL the splits for a transaction -- for example
>> when looking at my checking account it shows not only the split that credits
>> the register account, but also shows all the splits that debit the expense
>> accounts. When I look at any single account I am looking at more than just
>> the splits that affect that account, I am looking at all the related splits.
> 
> I am guessing that is because it only shows the splits for one
> transaction at a time.  The problem is that it needs to search all the
> splits for all the transactions at once and that is not available when
> the search is performed.
> 
>> 
>> That leads to another thought -- if the data can be displayed in the
>> register page, I would think it would be accessible from the search dialog
>> as well. Both of them start knowing only that they are supposed to display
>> information about a specific account -- the register displays all the
>> associated splits, but the find dialog does not.
>> 
>> Why can't you replicate whatever logic is used to display the register? What
>> am I missing?
> 
> The fact that the register only shows splits for one transaction at a time.

That's not correct. Select View>Transaction Journal to see all of the splits for all of the transactions. It's the default view for "Find" results windows.

It's not that we can't replicate the logic, it's that the Find code *doesn't* replicate the logic, because the author wasn't thinking of the use case that we're discussing here.  Patches welcome.

Regards,
John Ralls