GncBusiness v. GNCSession

[Linas Vepstas]

On Sun, Nov 25, 2001 at 05:33:55PM -0500, Derek Atkins was heard to remark:
> 
> Sometimes "better" is not necessarily better.  There is really a
> trade-off between technological superiority and usable functionality.

Argh... I'm frustrated.  That is not the trade-off.   Its the wrong 
analogy.

> If I had to choose between the two, I'd choose the latter (more
> functions vs. a highly superior technology).  Sure, this is why
> Micro$oft got where they are today (and why some of us hate them --
> for selling inferior technology), 

I couldn't disagree more.  Miscorsoft has been shipping some excellent
development tools for over 5+ years, and we still don't have anything
like it on Linux. I think KDE & The Kompany are starting to create
something similar, and there are other open source proehjcts for this,
but *none* of them approach the quality of the microsoft products.

These superior tools have allowed thousands of 'consultants' to
whip together gazillions of highly useful, highly-domain-specific,
niche software programs that fill every niche.  This is why microsoft is
so hard to displace: they've got zillions of apps.  Very few of these
zillions were hand-crafted the way we put together gnucash:  most
of them are hacks that are quickly constructed with powerful development
tools.  Tools that we simply aint got on Linux.

> > If the correct tools/infrastructure existed, it could be a *lot* easier 
> > to create new, complex apps.  However, creating the right tools & 
> > infrastructure is a lot of work...
> 
> Yea, yea.. Wishful thinking.  Vaporware.. Stuff like that.  KISS --
> hardcoded objects are, IMHO, easier and faster to deal with.

Simpler and faster only because you don't know the other way.  
Hard-coded objects take orders of magnitude more time to develop 
and debug.  Its a long, slow, tedious process.

> > > >  Conceptually,
> > > > the query must be representable as a tree, with AND/OR to join the
> > > > branches, and objects (aka tables) & field names & comparison ops 
> > > > appearing in the leafs.   Anything more complex than this is too much.
> > > > 
> > > > All we really need to do is to extend it so that arbitrary objects
> > > > and fields can appear in the query.  This means moving away from
> > > > the enums in sort_type_t, pd_type_t and pr_type_t.  Maybe these 
> > > > should be replaced with strings.  I think if you made them strings,
> > > > then it would be sufficient to get the function that you want.
> > > > I don't think you need anything fancier than this.
> > > 
> > > Quite honestly yes, this is sufficient.  
> > 
> > Do you think you have enough info to proceed with this kind of an
> > extension to query?  Or do we need to look at it a bit more carefully?
> 
> Honestly I think we need to look at it a bit more carefully.  I think
> I see where this is heading, but I'm going to have to study the Query
> object a bit more before I truly think that I've got it.  Also,
> another thing -- currently the Query always returns a GList* of
> Splits, no?  

two routines returns splits, the third returns transactions.

> How are we going to change that to query other types of
> data?

Part a) represent the query
Part b) execute the query

The above is a proposal only for part a.

> If we could always assume a SQL backend life would be much easier :)

No it wouldn't, for the six reasons I described in the previous note.

Really, Derek, just a week ago, our positions were reversed.  I was
suggesting that you hard-code something, and you insisted on
extensibility.  And now, you are just the opposite ...


> That notwithstanding, what I think we want is the ability to have
> nested ANDs and ORs where each QueryTerm has an object-type, and then
> an object-specific term and value.

Yes.  Each object has a number of fileds, and you have to be able to
specify ==, >, <, !=, etc on each field.

> I think I still need to think on this a bit more, in particular how to
> extend the Query to return, e.g., a GList* of GncCustomer or a GList*
> of GncInvoice, or...

yes.

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933