New data field for invoice object

[Derek Atkins]

John Ralls <jralls at ceridwen.us> writes:

> On Oct 9, 2011, at 6:09 PM, Derek Atkins wrote:
>
>     John Ralls <jralls at ceridwen.us> writes:
>
>         Nope, sticking it in KVP is bad, too, because without the type field,
>    
>         an older version of Gnucash will see the credit note data and think
>    
>         that it's a regular invoice and really screw things up.
>
>     Yes, I agree with this.  We can't just use a KVP.  We would also have to
>     add something that says that the feature has been used in the database.
>
>         I think that we must accept that we can't add the feature in a way
>    
>         that's safe for older versions, add the field to the Invoice table,
>    
>         and increase the version level on the database (and the XML file)
>    
>         which will prevent older versions of 2.4 from loading it.
>
>     However, I don't agree with that.  I think that there should be ways to
>     do it successfully.  c.f. my previous email about ext2 v ext3.
>
> Is that a comment from February of last year about running check and repair
> periodically?

No, it's a comment about an email I had composed a few minutes earlier
on this same thread.  It's not about scrubbing.  It's about being able
to read and interpret data that is readable and interpretable because
it's not using any new features.

In the XML world this is doable through an optional tag.  If the tag
does not exist then the feature isn't being used.  Older versions can
read and write the data just fine because there's no "new" data.  It
just works.

With SQL it's a bit more challenging because you need to be able to
"share" tables.  I still think it's possible to do this for this
particular case for SQL.

> The problem is that any new scrub code won't be in any older releases, and
> there obviously isn't already scrub code for Geert's new feature. Unless you
> can figure out how to do retroactive releases, we can't go forward if we
> insist that old code has to be able to handle changed data structures.

Keep in mind that we can still add code to 2.4.x so that e.g. 2.4.8
knows about the new features.  So it's not really a question of
retroactive releases per se, but making sure that the 'last' of the
previous stable releases can handle the data in future releases when
using the same feature set.

Keep in mind that there are different kinds of data (in)compatibilities.
There are syntactic and semantic issues.  When it's a syntax issue then
compatibility is easy because older versions wont understand the syntax
and can bomb out immediately.  For semantic differences you need a
"feature flag" which can tell older versions that there are semantic
differences that wont be understood.

This is where my ext2/ext3 example comes in.

> We could require only new data structures (which old code wouldn't be able to
> see), but ISTM that would only make worse an already bad data model.
>
> Regards,
> John Ralls

-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
       warlord at MIT.EDU                        PGP key available