John Ralls <jra...@ceridwen.us> writes:
> On Dec 8, 2010, at 6:36 AM, Phil Longstaff wrote:
>
>> Support for this already exists. There's a "versions" table which has
>> table-name/table-version pairs. This is loaded automatically when the file
>> is
>> opened. The backend code for each object type contains a "create tables"
>> routine which is called to create and/or update tables for that object type.
>> At
>> this time, if the table version is not current, it can be updated. There is
>> already some code for various object types which have handled some upgrades
>> through the 2.3.X series.
>>
>
> That addresses changes to the schema (that is, how many columns are in a
> table, what their names and types are, which ones are keys, etc.) but not
> changes to how the rows are saved and retrieved in the backend. The changes I
> made in r19729 and r19911 were in the latter category.
Maybe this is a silly question, but why couldn't we use the versions
table to notice this, too? It's still a bug in the SQL, and we should
get used to fixing SQL bugs internally.
I understand it might take a few tries to get right, but that's what
"mysqldump" is for. :)
> 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
warl...@mit.edu PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
