John Ralls jra...@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
On Dec 9, 2010, at 7:05 AM, Derek Atkins wrote:
John Ralls jra...@ceridwen.us writes:
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
On Dec 9, 2010, at 7:05 AM, Derek Atkins wrote:
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
On Thu, December 9, 2010 12:01 pm, John Ralls wrote:
On Dec 9, 2010, at 7:05 AM, Derek Atkins wrote:
John Ralls jra...@ceridwen.us writes:
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
On Dec 9, 2010, at 7:05 AM, Derek Atkins wrote:
John Ralls jra...@ceridwen.us writes:
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
--On December 9, 2010 10:24:51 AM -0800 John Ralls jra...@ceridwen.us
wrote:
Anyway, if we're going to introduce the gnucash-version row, we
should do it now, before 2.4 is released.
It seems like this is a good idea, even if it is never used for
automatic upgrades or fixups. At the very
John,
John Ralls jra...@ceridwen.us writes:
Everyone using a SQL backend who started with data saved from XML with a
Gnucash version before 2.3.16 should re-save from XML with 2.3.17 and
re-enter any intervening transactions.
I just fixed 635967 [1], which complained that scheduled
for it.
From: Derek Atkins warl...@mit.edu
To: John Ralls jra...@ceridwen.us
Cc: devel gnucash gnucash-devel@gnucash.org
Sent: Wed, December 8, 2010 8:23:46 AM
Subject: Re: SQL Databases from before 2.3.16
John,
John Ralls jra...@ceridwen.us writes:
Everyone using a SQL backend who
On Dec 8, 2010, at 5:23 AM, Derek Atkins wrote:
John,
John Ralls jra...@ceridwen.us writes:
Everyone using a SQL backend who started with data saved from XML with a
Gnucash version before 2.3.16 should re-save from XML with 2.3.17 and
re-enter any intervening transactions.
I just
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
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
On Dec 8, 2010, at 12:42 PM, Derek Atkins wrote:
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
Everyone using a SQL backend who started with data saved from XML with a
Gnucash version before 2.3.16 should re-save from XML with 2.3.17 and re-enter
any intervening transactions.
I just fixed 635967 [1], which complained that scheduled transactions didn't
work in 2.3.17 from a database
13 matches
Mail list logo
