Cannot find text or value inside a split

[Derek Atkins]

Don,

This is getting WAY beyond gnucash-user territory.  Further discussion
of this really belongs in -devel because we're getting way into
implementation details.

DonM <dm413-gc at intielectronics.com> writes:

>> 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.

That's a DISPLAY feature of the register, but has nothing to do with the
underlying search. The register still only queries for it's own splits,
but then it takes those splits and displays additional data based on
that split-list.  Please do not confuse or conflate the two parts.

During the DISPLAY portion, it takes that split-list and then explicitly
displays the split->parent transaction details (e.g. date, description),
and potentially data from other splits in the transaction (e.g. transfer
account in basic mode).  Moreover, except in the "journal" mode, a
register will have multiple entries for a single transaction if there
are multiple splits tying that transaction into the account.  This is
directly a result of the fact that they underlying query is:

  Split.Account == ThisAccount

> 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.

The fact that it can be displayed doesn't mean that it can be searched.
The reason is, as I said before, there is no way for the query
functionalty to perform the "AnySplit" functionality, which is VERY
different than the register displaying ALL the splits.  Moreover, as
I've said, the display is turned to the specific data objects
(splits+transactions) but the search is generic across *all* objects and
doesn't have any specific knowledge about the objects at all.

> Why can't you replicate whatever logic is used to display the
> register? What am I missing?

Because the display logic is specially tuned to Splits+Transactions,
whereas the search code is generic and applies to all objects.  The
search code does not have the ability, at a generic level, for a getter
to return a list of typed objects and then perform additional searches
within that list.  Part of this is due to the underlying pseudo-object
implementation: given a generic object pointer (gpointer) I cannot
easily know what the object is (split, transaction, account, fooObject,
etc).

There are many reasons that this is the way it is, and there are
multiple ways forward, but the main problem is that the underlying GLib
list (GList) returns a list of generic pointers instead of a list of
typed pointers.  Changing this would require one of a couple of options:

1) Guess.  Take the gpointer and *guess* that it's a FooType, and hope
   you're right (with catestrophic effect if you are wrong).

2) Fully finish converting to GObject, at which point we can query the
   gpointer as a gobject and ask it what its type is.  This still has
   the issue that if you have a list of non-gobject pointers you're back
   to #1.

3) Use a language with better typing and interfaces, like C++.  Then we
   could literally return a list of Splits, and each Split would
   implement the "Queriable" interface, etc, etc, etc.

Once we fix some of these, then we need to augment the Query interface
to add a new predicate that can handle a list-of-objects as a return
from a getter and allows you to apply additional queries to each of
those objects, with "anymatch", "eachmatch", and "nonematch" options.
However even this gets to be challenging, because what happens if you
get to a list-of-lists?  Basically, once you get into the details it can
get very complicated very quickly.  So this is why it doesn't exist.

Patches are always welcome!

> Don

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available