On Thu, Oct 19, 2006 at 05:42:22PM -0400, Derek Atkins wrote: > Quoting Chris Shoemaker <[EMAIL PROTECTED]>: > > >>It looks like the symbols query-compare-equal and guid-match-any have > >>been turned into numeric parameters in the new query. (The GUIDs > >>changed since I probably selected a different account.) I don't know > >>whether the bug is in the processing of the query or the generation of > >>the query. > > > >Yeah, the swig wrappers wrap enums as numbers, while the g-wrap > >wrappers wrapped them as symbols. For that reason, and probably many > >more, in theory, saved reports from 2.0 (g-wrap) may be unreadable in > >2.2. In practice, I think most reports will work fine, but saved > >queries won't. > > This isn't a good idea.. It means that anytime you change the values > in an enum ALL your saved state goes bad!! What's the point of using > an enum if it's not stable? > > Is there any way we can fix this -- at least in certain places where we > stringify the enums?
There are two issues here: One is that pre-swig saved state is incompatible with new swig wrappers. E.g. the old file had "query-compare-equal" while the swig-wrapped constant is "QOF-COMPARE-EQUAL". I don't think this is worth solving. The other issue is some saved state is now stringified with the numeric constant values instead of their names. IIRC, the way this worked before was that C code in engine-helpers.c would dynamically construct strings that would form the names of g-wrap generated mapping functions. Then, the string could be evaluated using scm_c_eval_string() and turned into a procedure which could then be called using libguile, passing the value of the constant. The g-wrap generated mapping function would return a symbol corresponding to the value of the constant. From there, I think the symbols were later automatically stringified by guile's (write ...) function. AFAIK, this technique was only used for query attributes, and only those that are enums, and not even all of _those_. Even with the old g-wrap code, we were saving numeric values for some query attribute enums like KvpValueType. (BTW, this code had been rotting since the linas days, c.f. "gnc_scm2KvpValueTypeype" (sic) which used to be called "gnc_scm2kvp_value_type"). I'm sure there's some smart, maintainable way to completely serialize the query while de-coupling it from the C enum definitions, but the old g-wrap solution was incomplete and a huge mess. Now it's simply gone. :) Maybe one solution is to change the guile representation of the query to just use symbols internally, and then provide our own mapping from enums to symbols, and vice versa. We already have > 2k LOC (just in C) dedicated to serializing and unserializing the query. What's a few hundred more, right? :( -chris _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
