Derek Atkins wrote: > Hi, > > Phil Longstaff <[EMAIL PROTECTED]> 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?). Phil _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
