Chris Hostetter wrote: > this is off the subject of the heap space issue ... but if the id changes, > then maybe it shouldn't be the uniqueId of your index? .. your code must > have someone of recognizing that article B with id 222 is a changed > version of article A with id 111 (otherwise how would you know to delete > 111 when you insert 222?) ..whatever that mechanism is, perhaps it should > determine your uniqueKey?
No, there is no "key" or something that reveals a relation between new article B and old article A. After B is inserted and A is deleted, all of A's existence is gone and we do not even know that B is A's "successor". Changes are simply kept in a table which tells the system which IDs to delete and which new (or changed) articles to insert, automatically giving them new IDs. I know this may not be (or at least sound) perfect and it is not the way things are handled normally. But this works fine for our needs. We gather information about changes to our data during the day and apply them on a nightly update (which, I know, does not imply that IDs have to change). So, yes, I'm sure I got the right uniqueKey. ;-) Marcus
