GDA: empty PostgreSQL table failed workaround

Phil Longstaff plongstaff at
Wed Feb 13 13:57:17 EST 2008

Derek Atkins wrote:
> Hi,
> Phil Longstaff <plongstaff at> writes:
>> Saving to the db deletes all tables and then recreates them.  It 
>> therefore deleted the slot_id without the default value.  It wouldn't 
>> have touched the sequence.  I'll need to build your workaround into a 
>> rev and then let you try it.  There's also an argument to be made that I 
>> should create some test cases and set up automated tests for sqlite, 
>> mysql and psql.  Maybe once I'm over these initial hurdles and some 
>> people are working with the code.
>> Yes, the recurrence table would have the same problem.  All of the other 
>> tables are for objects which have a guid as the main reference (and 
>> therefore as the table's primary key).  Slots and recurrences attach to 
>> an object but there can be more than one attached to any object.
> I'm sure this is going to display my utter lack of knowledge about
> DB systems, but...  Why do you need a slot_id or recurrence_id column
> at all?  I would think that you would always just do something like:
>   select * from slots where slot_guid=<object guid>
> or:
>   delete from slots where slot_guid=<object guid>
>   insert into slots values (...)
> Yeah, this isn't quite as nice as using an update, but it certainly
> works.  I could imagine a similar thing for the Recurrence table.
> Thanks for your indulgence...

For slots (and recurrences), I select slots as you suggest and for a 
commit, I already do as you suggest (delete followed by insert) because 
there isn't a guaranteed number of slots for the object.  For an 
account, for example, tax status, hidden status and placeholder status 
are kept as slots with boolean values.  However, before you check any of 
the dialog checkboxes, the account has no slots.  It would be too hard 
for the gda backend to look at the slots in the db, the slots to be 
saved when the object is updated, and come up with the best set of 
insert/update/delete statements.  It just wipes and saves again.

The slot_id is used to provide a unique primary key.  I don't know if it 
would work to have the slots table have *no* key, but have an index on 
the obj_guid field.  The obj_guid field can't be the primary key because 
I believe a primary key needs to be unique.  Mark?

Derek, any thoughts on the 3.x vs 1.3.x question (from another thread)?  
If we try to target the gda backend for GC 2.4 (I saw a suggested 
release date near the end of the 2008), what is the "supported" set of 
linux releases (fedora 6 and above, suse 10.3 and above, mandriva 2007 
and above, ...).  My guess is that many of them will still have 1.3.x, 
though 3.x will be available (or would the GC project need to supply 
built libgda binaries in a case where we depend on a version newer than 
is supplied in the distro?).


More information about the gnucash-devel mailing list