Exponential growth of the slots table

John Ralls jralls at ceridwen.us
Sat Dec 4 12:22:46 EST 2010


On Dec 4, 2010, at 9:06 AM, Phil Longstaff wrote:

> On Sat, 2010-12-04 at 07:41 -0800, John Ralls wrote:
>> On Dec 3, 2010, at 10:42 PM, Phil Longstaff wrote:
>> 
>>> The slots table contains extra information for the other objects.  This extra 
>>> information allows extra values to be tied onto objects.  It will be loaded and 
>>> saved with the objects.  When loaded, the slots are like a directory structure.  
>>> At each level, there are named keys with values of different types (int, string, 
>>> date, ...).  There can also be sub-levels.
>>> 
>>> The main key is the guid field which contains the guid of the object that this 
>>> slot belongs to.  This object can be of any other type (account, split, 
>>> transaction, book, ...).  The other fields in the slot table are the full 
>>> directory path of the key, the value type, and the value.
>>> 
>>> I believe that guid/path should be unique.
>> 
>> That's only part of the story: Using full paths (not really directory paths, more like xml XPaths except that the components are the the string values of the slots:key elements rather than element names... which is the source of Bug 635859 [1], because the the delimiter character '/' is allowed in string data (though not in element names). didn't work for hierarchies of slots, which are used in several places (Bug 627831 [2]): Child elements were silently not created during load. r19729 added recursion to the slot storage so that each level is stored as a row, and slots with children (either of type frame or type list) get a guid_val created on the fly -- which is discarded on load to provide for exact round-tripping to xml -- which is used as the obj_guid to link children to their parents. 
>> 
>> But that isn't the problem: The problem is that save_slots doesn't query to see if a slot record exists before inserting it -- and the slot table's primary key is an autoincrement, so there isn't a key conflict, either.
> 
> No, it doesn't query if it exists, but it is supposed to delete all
> slots for the object before it starts to save.

OK, I was thinking along those lines as a fix. Perhaps all that needs to be done is to make that recursive as well.

Regards,
John Ralls



More information about the gnucash-user mailing list