Exponential growth of the slots table

[Elwood Hunt]

So, the slots table sounds like a metadata table.  Is there anything I can
do about the thousands of extra rows or should I just wait for a fix?

On Sat, Dec 4, 2010 at 9:55 AM, Phil Longstaff <plongstaff at rogers.com>wrote:

> On Sat, 2010-12-04 at 09:22 -0800, John Ralls wrote:
> > 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.
>
> I don't know what the issue might be.  It deletes all slots which match
> the object guid.  I'm not sure what you mean by making it recursive.  It
> doesn't use the path.
>
> Phil
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>