On Oct 8, 2011, at 9:23 AM, Geert Janssens wrote: > I'm working on introducing full credit note support in GnuCash [1]. After > thinking it through for a long time I came to the conclusion I will need to > add an extra parameter to the invoice object that has to be saved and > restored > from the data file. > > I could use a new kvp, so older versions of GnuCash won't have any problems > with this. The thing is though that credit notes require changes as such a > fundamental level in de business logic that older GnuCash versions will > probably choke on them anyway, or create wrong results. So backward > compatibility is not really feasible. > > And since kvp's are not nice for the sql backend, I think it will be better > to > use a true field. > > I never added a field, and we have two major backend technologies now. So I'm > asking some input on how to best proceed. > > Derek suggested on irc to make it an optional field so that if credit notes > are not used, older versions of GnuCash can still work with the data file. I > can imagine this with the xml backend, but is such a thing possible with the > sql backend as well ?
Geert, The way you'd implement an optional type field in an RDB is to create a new table for it with two fields, a key (which would be the invoice GUID) and the type, and the code for handling that table would have to examine the database version and not use it if it's an older version. Similarly, your new credit note code would have to check with the backend to see if it's OK to create the note, because an older version of Gnucash will do the wrong thing with the data. This is a Bad Idea. We're tying ourselves in knots worshipping backward compatibility. The current data model is not a good design, but we can't fix it if we have to stay bidirectionally compatible with older versions. I don't remember offhand what distinguishes a bill from an invoice, but I think it's which set of (identical) fields in the entry table are filled, which is a poor design. I suggest that in the interest of better normalization you go ahead and create the type field and consider collapsing into a single table the invoice and entry tables -- or at least shrink the entry table to a single set of fields (instead of the current, identical, i_ and b_ sets) -- the purpose of which is determined by the type field. While I'm ranting, another poor design choice that jumps out is addresses. The same fields exist twice in the customer table, once in the vendor table, and once in the employee table. There should be a single address table, and the other tables should have a foreign key to its primary. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
