Opening saved account reports

[Chris Shoemaker]

On Thu, Oct 19, 2006 at 05:42:22PM -0400, Derek Atkins wrote:
> Quoting Chris Shoemaker <c.shoemaker at cox.net>:
> 
> >>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