Re: General Query Framework, a proposal
Dave Peticolas [EMAIL PROTECTED] writes: Thanks, this looks like a great start. Thanks. [snip] I realize that isn't list isn't comprehensive, but we should support all the basic kvp types, including int64 and double. Also, boolean would be good, too. True, but this list is comprehensive in that it covers everything that the current Query can cover. But yea, we should be able to cover all the KVP types. [snip] Or just add a 'character' type, maybe. That would work, too, and the predicate data can be a list of wanted characters. The attached files are the current (incomplete) header files. Please let me know what you think so far. From my reading of the API, it looks like each object data member (account name, account code, etc), is registered individually. Is that right? What about dynamic kvp data? Yes, you read it right. Keep in mind that each 'type' defines it's own predicate-data object I need to think about the kvp data. My first off-the-cuff idea would be to define a 'kvp' type, register the kvp-getter, and in the predicate-data define the slot/frame name, type, and data. Or perhaps have it recurse a bit? Like I said, I have to think about how to handle kvp data. Do you have any ideas? dave Thanks for your comments, Anyone else have anything to say? -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: General Query Framework, a proposal
On Tue, 2002-01-29 at 08:15, Derek Atkins wrote: Dave Peticolas [EMAIL PROTECTED] writes: Thanks, this looks like a great start. Thanks. [snip] I realize that isn't list isn't comprehensive, but we should support all the basic kvp types, including int64 and double. Also, boolean would be good, too. True, but this list is comprehensive in that it covers everything that the current Query can cover. But yea, we should be able to cover all the KVP types. Oh, well in that case you're just wrong :) You missed the 'kvp' query api, unless you were looking at the stable sources. [snip] Or just add a 'character' type, maybe. That would work, too, and the predicate data can be a list of wanted characters. The attached files are the current (incomplete) header files. Please let me know what you think so far. From my reading of the API, it looks like each object data member (account name, account code, etc), is registered individually. Is that right? What about dynamic kvp data? Yes, you read it right. Keep in mind that each 'type' defines it's own predicate-data object I need to think about the kvp data. My first off-the-cuff idea would be to define a 'kvp' type, register the kvp-getter, and in the predicate-data define the slot/frame name, type, and data. Or perhaps have it recurse a bit? Like I said, I have to think about how to handle kvp data. Do you have any ideas? Well, first take a look at the existing api. dave signature.asc Description: This is a digitally signed message part
Re: General Query Framework, a proposal
Dave Peticolas [EMAIL PROTECTED] writes: I realize that isn't list isn't comprehensive, but we should support all the basic kvp types, including int64 and double. Also, boolean would be good, too. True, but this list is comprehensive in that it covers everything that the current Query can cover. But yea, we should be able to cover all the KVP types. Oh, well in that case you're just wrong :) You missed the 'kvp' query api, unless you were looking at the stable sources. :-P It handles everything except KVP and RecnCells -- is that better? [snip] Well, first take a look at the existing api. Yea, and the current KVP basically does what I said: you pass it a slot path and a kvp_value to compare against ;) dave -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: General Query Framework, a proposal
On Tue, 2002-01-29 at 15:23, Derek Atkins wrote: Dave Peticolas [EMAIL PROTECTED] writes: I realize that isn't list isn't comprehensive, but we should support all the basic kvp types, including int64 and double. Also, boolean would be good, too. True, but this list is comprehensive in that it covers everything that the current Query can cover. But yea, we should be able to cover all the KVP types. Oh, well in that case you're just wrong :) You missed the 'kvp' query api, unless you were looking at the stable sources. :-P It handles everything except KVP and RecnCells -- is that better? [snip] Well, first take a look at the existing api. Yea, and the current KVP basically does what I said: you pass it a slot path and a kvp_value to compare against ;) Sounds good. dave signature.asc Description: This is a digitally signed message part
SX editor bug (?)
Using gnucash 1.7.0 from cvs dated 1/21/02. I recently had occasion to change the amount of the SX for my weekly pay (tax law changes...). The SX has three entries: a debit to Checking, a debit to Savings and a credit from Inc Sal. When I change the amount of the debit to checking and tab thru the rest of the line, I am presented with a empty register window rather than the next line in the SX (by empty I mean that all entries have disappeared from the window and I'm presented with an empty register line). If I press Cancel and the bring the SX back up into the editor, the change I made to the Checking debit is accepted, but the rest of the SX becomes unbalanced (I didn't get to off-set the debit change with a credit change). This happens regardles of which line I change. If I don't make a change, I can tab thru the lines normally. Regards, Tim -- Caldera eWorkstation 3.1, kernel 2.4.9, KDE 2.2.1, Xfree86 4.1.0 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
General Query Framework, an updated proposal
Ok, here is an updated set of headers. I've flushed out the types a
bit more as per your suggestions, and I've flushed out the model as
well.
There are now three registries:
1) core data types
2) gnucash objects' data parameters
3) gnucash objects' parent objects
The third registry basically allows you to register functions that
basically say: given a split, return the account and then perform
queries against the account object.
When you build a query term, you basically supply an object_type,
parameter_name, comparitor, predicate_data, and query_operator. When
you run the query, you tell the query what kind of object you're
looking for and it will iterate over those objects. For each term it
uses registry 3 to convert from the requested object to the querried
object, registry 2 to lookup the core type and access function, and
registry 1 to look up the match_predicate function. In this way
you can build a query that says:
Return all splits where account-account_name equals regex (name)
In this example:
- split is the requested object,
- account is the querried object,
- account_name is the parameter (of type QUERYCORE_STRING),
- equals is the comparitor,
- regex (name) is the predicate_data (for type QUERYCORE_STRING)
I _think_ that this API can fully implement the existing Query API.
Please send me comments.
Thanks,
-derek
/*
* QueryNew.h -- API for finding Gnucash objects
* Copyright (C) 2002 Derek Atkins [EMAIL PROTECTED]
*
*/
#ifndef GNC_QUERYNEW_H
#define GNC_QUERYNEW_H
/* A Query */
typedef struct querynew_s QueryNew;
/* Query Term Operators, for combining Query Terms */
typedef enum {
QUERY_AND=1,
QUERY_OR,
QUERY_NAND,
QUERY_NOR,
QUERY_XOR
} QueryOp;
/* Standard Query Term comparitors, for how to process a query term.
* Note that not all core types implement all comparitors
*/
typedef enum {
COMPARE_LT = 1,
COMPARE_LTE,
COMPARE_EQUAL,
COMPARE_GT,
COMPARE_GTE
} query_compare_t;
/* Types of Gnucash Queriable Objects (const char *) */
#define QUERY_TYPE_SPLITsplit
#define QUERY_TYPE_ACCOUNT account
#define QUERY_TYPE_TRANSACTION transaction
/* Type of Query Core Objects (String, Date, Numeric, GUID, etc. */
typedef const char * QueryCoreType;
/*
* List of known core query types...
* Each core query type defines it's set of optional comparitor qualifiers.
*/
#define QUERYCORE_STRINGstring
typedef enum {
STRING_MATCH_CASEINSENSITIVE = 1,
STRING_MATCH_REGEXP
} string_match_t;
#define QUERYCORE_DATE date
typedef enum {
DATE_MATCH_ROUNDED = 1
} date_match_t;
#define QUERYCORE_NUMERIC numeric
typedef enum {
NUMERIC_MATCH_ABS = 1,
NUMERIC_MATCH_NEG_ONLY,
NUMERIC_MATCH_POS_ONLY
} numeric_match_t;
#define QUERYCORE_GUID guid
typedef enum {
GUID_MATCH_ALL = 1,
GUID_MATCH_ANY
GUID_MATCH_NONE
} guid_match_t;
#define QUERYCORE_INT64 gint64
#define QUERYCORE_DOUBLEdouble
#define QUERYCORE_BOOLEAN boolean
#define QUERYCORE_KVP kvp
/* A CHAR type is for a RECNCell */
#define QUERYCORE_CHAR character
/* Basic API Functions */
/* This is the general function that adds a new Query Term to a query.
* It will find the 'obj_type' object of the search item and compare
* the 'param_name' parameter to the predicate data via the comparitor.
*
* For example:
*
* acct_name_pred_data = make_string_pred_data(STRING_MATCH_CASEINSENSITIVE,
* account_name);
* gncQueryAddTerm (query, QUERY_TYPE_ACCOUNT, QUERY_ACCOUNT_NAME,
* COMPARE_EQUAL, acct_name_pred_data, QUERY_AND);
*/
void gncQueryAddTerm (QueryNew *query,
const char *obj_type, const char *param_name,
query_compare_t comparitor, gpointer pred_data,
QueryOp op);
/* Run the query:
*
* ex: gncQueryRun (query, QUERY_TYPE_SPLIT);
*/
GList * gncQueryRun (QueryNew *query, const char *obj_type);
#endif /* GNC_QUERYNEW_H */
/*
* QueryCore.h -- API for providing core Query data types
* Copyright (C) 2002 Derek Atkins [EMAIL PROTECTED]
*
*/
#ifndef GNC_QUERYCORE_H
#define GNC_QUERYCORE_H
#include QueryNew.h
#include QueryObject.h/* for QueryAccess */
/*
* An arbitrary Query Predicate. Given the gnucash object and the
* particular parameter get-function (obtained from the registry by
* the Query internals), compare the object's parameter to the
* predicate data given the match_options
*/
typedef int (*QueryPredicate) (gpointer object,
QueryAccess get_fcn,
query_compare_t how,
gint match_options,
gpointer pdata);
/* A callback for how to destroy a query predicate's pdata */
typedef void (*QueryPredDataFree) (gpointer pdata);
/* This function registers a new Core Object with the QueryNew
*
