Cannot find text or value inside a split

[Colin Law]

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.

Colin