[elephant-devel] Secondary DB behavior

[Robert L. Read]

I seriously doubt that is the intended behavior.

It seems to me that is a very serious bug (possibly a relatively recent
one, as well.)

It is unfortunate that we don't have  test that would detect that.  If 
you have the energy, please write such a test (probably based on code
you
already have.)

If you can't do it, I will be able to do it, but not until later this
week.


On Sat, 2006-01-28 at 14:37 -0500, Ian Eslick wrote:

> This was not clear in the documentation, but secondary db's appear to
> have the following behavior.
> 
> btree - an indexed btree
> inverted - an secondary index of btree
> fn - A function that computes the secondary key given the value given to
> btree
> 
> Write pkey/value1 into btree
> inverted has fn(value1)/pkey
> 
> Change the association of pkey by writing
> pkey/value2 into btree
> 
> inverted now has:
> fn(value1)/pkey
> fn(value2)/pkey
> 
> Namely, each secondary index contains the entire history of the values
> of pkey and associates
> them with pkey.  If you are sorting and searching objects by using
> secondary indices this is
> not very useful. 
> 
> Is this the intended functionality?  This could be a setup problem on my
> end or the way secondary
> indices were intended to work.  In which case it makes sense for me to
> make sure that when
> a secondary value changes, the original secondary key/value pair is
> deleted from the secondary
> index.  I just discovered this and the uniqueness of mappings to pkey in
> the above example is
> crucial for my application.
> 
> Thank you,
> Ian
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20060128/d1430604/attachment.html>