Just thinking ahead to conversion of the sql database to a true database, not just storage which is what it currently is.
For most tables, we could add FOREIGN KEY constraints so that in the splits table, for example, the tx_guid which specifies the transaction to which the split belongs must be a valid guid key in the transactions table, and the same for the account_guid and the accounts table. I do happen to know there at one point when a lot is being created, it can be saved with account=NULL, so that the NOT NULL constraint was removed from the lots table account_guid at one point. However, we should be able to modify the code so that a lot is never saved with account=NULL. Back to the slots table. The obj_guid field which indicates which object this slot belongs to can refer to a guid in any other table, so we can't have a meaningful FOREIGN KEY constraint. Should we split the table so that we have account_slots, tx_slots, split_slots, etc. tables, one for each object type? Each xxx_slots table would have an obj_guid field which would have a FOREIGN KEY constraint referring to the xxx table. The slots table can hold slots of type "GUID" which contain a reference to another object. Unfortunately, there's no FOREIGN key constraint we could use unless we split that field to have an account_guid, a tx_guid, a split_guid, etc. Phil _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
