SQL Databases from before 2.3.16

[Derek Atkins]

John Ralls <jralls at ceridwen.us> writes:

>> 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.  :)
>
> The versions table has only one row for each table, having the table
> name and a version number. As long as the schema of the table doesn't
> change, different versions of Gnucash whose table description array
> matches the schema can write to the table... but they might understand
> the data differently. That's a row-by-row difference and the version
> table isn't fine-grained enough to capture it. That's the way it works
> now.

Sure, it defines the syntax and semantics of the table, which makes
sense.  In this particular case an older version may not know what to do
with the newer table structure, so it probably does have to throw an
error and say that an update is required.  Right?

> But we could add a row to the versions table with the last Gnucash
> version to touch the database. When we write a change to the backend
> that changes the way data are stored, we can invoke a routine that
> reads everything in the old way and writes it back out the new way,
> then updates the gnucash entry in the versions table. Older versions,
> not knowing what newer versions have changed, would have to punt with
> an error dialog ("Sorry, the database has been written by a newer
> version of Gnucash. This version can't safely read it.") It would get
> unwieldy in pretty short order (like the scrub routines in engine),
> but we could do it.

I think you're right that this is almost exactly like a "Check &
Repair."  The "Check & Repair" function exists to fix bugs that cause
broken data to enter the database.  In this particular case, I don't
think we need to prevent older versions from reading a database that was
"checked & repaired" by a newer version of GnuCash.  It's perfectly
reasonable to expect that older versions can read newer versions.

> All of which is entirely skew to cleaning out the extra rows in
> Elwood's slots table.

Is it?  I would think that a "Check & Repair" would exactly do that.

In this case the "Check & Repair" state would get re-written on every
run of GnuCash.  You use it to know whether or not you need to run the
C&R functionality on the database.  If the database was last touched by
a version >= current-version then you don't need to run the C&R.
However if the last database write was from a version < current-version,
then C&R is required.

The requirement would be that you set LastC&R to "current-version" any
time you make changes to the database, and then you check the LastC&R
whenever you startup.

> Oh, and there isn't enough sql yet to have "bugs in the sql". 

The fact that we're having this discussion would prove this incorrect.
There already has been a bug in the SQL causing the slots to not get
deleted properly.

>   The sql
> is all very simple (select * from foo where guid="bar" is about as
> complex as it gets right now) with all of the interesting work done by
> qof. 

Yes, I understand that.  But even simple SQL can have logic bugs.

>    Rather a waste of an RDB, frankly. We'll have to change that in
> order to support multiple access, and the redesign will probably reach
> through qof into the engine. That will be another discussion, for
> after we get 2.4 released.

Agreed, but as you say it's an after-2.4 thing.  Much of GnuCash
currently depends on having all the data in core.  It will require a
thorough cleaning of all those assumptions in order to "fix" that.

Let's get 2.4 out the door first, and then we can talk about how we can
fix this in a piecemeal fashion.  It would be nice if we could get
releases out approximately yearly.  Can we come up with a
feature-set/timeline that would allow for that (and makes sense)?

> 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