(AUDIT?) Re: r14892 - gnucash/trunk - Add a new QOF_TYPE_NUMSTRING to add numeric sorts. (#150799).

[Chris Shoemaker]

On Tue, Sep 26, 2006 at 09:19:12AM -0400, Derek Atkins wrote:
> Quoting Chris Shoemaker <c.shoemaker at cox.net>:
> 
> >What about...?
> >
> >3) Leave sorting out of the type-system altogether and sort only in
> >the view.  Save the sort preference in GConf.  (BTW, that's how it
> >works in all the GtkTreeModel/View pairs, including on the
> >register-rewrite branch.)
> 
> That doesn't work with SQL backends when you want to return a subset of
> the responses.   

Playing the devil's advocate...

A) We don't really have a working SQL backend.  B) and no one is
really working on one.  But ignoring that for now...

> For example, if I wanted to do something like:
> 
>  select * from Split where <...> order by <...> limit 10;
> 
> In this case, the "order by" clause is important in the underlying
> query.    If you don't get the 'order by' correct then you'll get
> the "wrong" objects returned, which probably isn't what you want.

Well, you get the "right" objects, just in the wrong order.  If the user
changes the sort from ascending to descending, do you want to requery
the backend with different SQL?  Of course not.  You just reorder all
the objects you already have.  This is true for any sorting operation.

> Either that or you need to full working copy of all your data
> in core, which can get very expensive in large data sets.

By "core" do you mean L1 data cache or just RAM?  Either way, I'm
_very_ skeptical of design decisions made with this motivation.
Assuming you mean RAM, I would assert that the number of users who: 

a) would consider using GnuCash and

b) have a financial dataset whose in memory (not on disk)
representation is even 1/10 of the amount of RAM that came in the
machine they want to use for GnuCash

is actually zero.


Yes, I understand that QOF was designed to handle NASA's multi
petabyte image databases.  I just think it's unnecessarily burdonsome
to perpetuate that design requirement in GnuCash's QOF when it doesn't
benefit any GnuCash users.

I think it's _especially_ beneficial to drop the "our database might
be bigger than RAM" ideas as we consider options for
extending/rewriting QOF in the future.

BTW, I don't object to this current changeset, or even backporting it.
This is just the way QOF is today.  I'm only concerned that we
re-evaluate that design decision going forward.

Just my $(small number)/$(xaccCommodityGetFraction(comm)) $(gnc_get_default_currency()).

-chris