New data field for invoice object

Alex Aycinena alex.aycinena at
Mon Oct 10 12:05:34 EDT 2011


Attached find the 'final-entry-num.diff' file which you could modify
to remove the 'entry-num' changes I had planned and insert instead
your new field changes. Comments about the changes:

- src/backend/sql/gnc-transaction-sql.c: Since a new field is being
added, I bump up the table version, define the field length for the
new field and add code to upgrade an existing table using capabilities
provided by Phil's sql work. Instead of this you would do
corresponding work in another appropriate source file.

- src/backend/xml/io-gncxml-v2.c: To prevent currently released
versions of the xml back-end from bombing if you define any new
fields, you need to bump up the GNC version string. You would want to
do the same but change the comment about the reason. To get it to read
both the new and the prior versions, I changed the routine that
determines the xml file version from returning a boolean to return the
file type as defined in an enum in 'gnc-backend-xml.h'. Then the type
is used to pass the proper value to the parser. I think this could
apply to your changes as is.

- src/backend/xml/gnc-backend-xml.c: This change replaces the returned
boolean with the file type. Also this logic will allow released xml
back-ends to recognize files from a newer version and to report this
to the user upon load (which the currently released versions can't do,
unfortunately) and refuse to load later versions. I think this is the
right approach rather than reading part of the newer file and
'throwing away' the stuff it doesn't understand. I think this would
apply to your work as well.

- src/backend/xml/sixtp.c: Modify routine to return file type rather
than boolean. I think this would apply to your work as well.

- src/backend/xml/gnc-transaction-xml-v2.c: These changes add the new
entry-num field to the transaction. You would make corresponding
changes to another appropriate file instead.

- src/backend/xml/io-gncxml-v1.c: Needed to reflect change in return
type. This would apply to you if you make the other changes.

- src/import-export/log-replay/gnc-log-replay.c &
src/engine/TransLog.c: Add entry-num to log writing and replay. I
don't believe this applies to your new field.

- src/libqof/qof/qofbackend.h & src/libqof/qof/qofsession.c &
src/gnome-utils/gnc-file.c: Define and handle new error type. Also,
clarify, for the SQL_DB_TOO_NEW error, that data may be lost if user
elects to load, as current systems lets him/her do. I think this would
apply to your change.

- src/engine/Split.h & src/engine/SplitP.h & src/engine/Transaction.c
& src/engine/Transaction.h & src/engine/TransactionP.h &
src/engine/Split.c: These changes add the engine capability for the
entry-num field. You would make similar changes to corresponding files
instead of these.

- This change is needed for the sql backend to recognize
that the version number of the saved database is earlier than that of
the current application and that an upgrade is needed. Here you would
put the svn revision number of the commit where you apply these
changes to trunk.

- src/backend/xml/io-example-account.c: The arguments to
'gnc_is_our_xml_file' need to change but since this function
(gnc_is_example_account_xml) isn't used anywhere, I simply comment it
out. You would need to do the same if you use the changes above.

- src/backend/xml/test/test-xml-transaction.c & test-dom-converters1.c
& test-date-converting.c & test-xml-account.c &
test-string-converters.c & test-load-xml2.c & test-xml-commodity.c &
test-file-stuff.c & test-xml-pricedb.c & test-kvp-frames.c: Because of
the other changes, I needed to change various test files to get 'make
check' to work. You would also have to apply some of these depending
on which of the above you apply.

For the entry-num addition, these changes have been tested and work
properly for the following conditions:

        1. open old xml -> save as new xml
        2. open old sql -> save as new sql
        3. add fields to new xml -> read & write
        4. add field values to new sql -> read & write
        5. open new xml with new fields -> write to sql
        6. read new xml with new fields in prior version of gnucash
        7. read new sql with new fields in prior version of gnucash
        8. log replay with xml with new fields - add values to log
        9. log replay with sql with new fields - add values to log
        10. open new sql with fields -> save as xml
        11. read future version of xml with new gnucash
        12. read future version of sql with new gnucash

In addition, make check worked.

Let me know if you have any questions. By the way, I'm currently
traveling (I am in Brussels though I live in California; I believe you
are in Belgium?) so I'll try to check e-mail regularly to be available
to you.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: final-entry-num.diff
Type: text/x-patch
Size: 50005 bytes
Desc: not available
URL: <>

More information about the gnucash-devel mailing list