On Thu, Jun 12, 2003 at 11:04:49AM -0400, Derek Atkins was heard to remark:
> >
> > Smells like 'relational' to me. I think the predicates you need to
> > add are "has_a" and "is_a", but I'm not an expert .. I vaguely remember
> > "uses_a", "child_of" and "parent_of" ... and some arguments about what
> > the correct primitve predicates should really be.
>
> Well, currently my predicates are based on type-comparrisons, and each
> QueryCore type has its own predicates. For example a string predicate
> has a two predicates, "matches" and "doesn't match". Then there are two
> additional predicate flags: "match-case-insensitive" and "match-regex".
yeah, that's OK.
> There is not a generic "equals" predicate.. It's based on a data
> type.
That's OK. as long as the difference between equals and equivalent is
clear.
> So, as I said, I could build an "AccountGroup" predicate type,
Uhh, now you are making me expend brain cells. I probably will
get this all wrong, but I think the textbook would say that you
need an 'object' predicate, with the comparisons is_a and has_a.
So
AccountGroup has_a GUID ==> T
numeric has_a GUID ==> F
I'm not sure what happens next:
AccountGroup has_a GUID && GUID == val ==> T if it has that GUID value ??
AccountGroup has_a Account ==> T whenever the group has subaccounts
AccountGroup has_a Account && Account has_a GUID && GUID == val ==>
T whenever the group has subaccounts, one of which has the given
guid ??
I'm really not clear on this.
Transaction has_a description ==> T always
Transaction has_a string ==> T always (in fact, trans has several
strings, e.g. memo)
description is_a string ==> T always
Transaction has_a description && description is_a string ==> T always
Transaction has_a description && description is_a string && string == val
is true only if the transaction description matches the val.
Then there's joins:
Transaction has_a x && x is_a string && string == val
would return matches on description or memo or any string stored in the
transactions kvp tree ... !??
And finally there are lambda's or unbound vars:
Transaction has_a date && date == x
is a predicate that only acts on date values that are a part of
transactions.
You can use the lambda-thingy to build complex predicates (at run-time
instead of compile-time). I guess. Something like that.
> but it would be much better if I could base it on the existing "GUID"
> match.... However the GUID match requires you to match against a list
> of GUIDs. I'd have to think about how to possibly extend this to
> provide parental searches.
I think it would be fruitful to skim the literature for ideas. Besides
(or instead of) is_a, has_a, there are other ways of combining things,
some supposedly better than others. I think this dates back to the
70's/80's when things like relational and object-relational were being
hotly debated. I'd be happier if what you came up with was grounded
in theory.
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
