This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I'm currently using KeyTable for my context's IdentityMethod property. I also have UpdateBatchSize set to 1.
Ideally I'd like to have the KeyTable table hold the IDs from the deleted entities too, so that new entities can reuse them. Any chance to have this implemented? Maybe as an opt-in setting so that users that don't need this don't have to sacrifice the better performance that the current approach presents. |
|
|
|
|
I've logged a feature request for this, but it's extremely unlikely we'll implement it. Integers aren't a scarce resource *grin*, so there's no real benefit in recycling them: indeed there are significant downsides in terms of complexity and performance (as you note). If you're concerned about running out of IDs, change up to longs instead of ints. You will never run out of 64-bit IDs. If running out of IDs isn't the concern, could you say a bit more about the problem you're trying to solve here? |
|
|
|
|
Ivan: I think you should add "Integers aren't a scarce resource" to the FAQ ;-) |
|
|
|
|
Well not that I was really worried about running out of values, just thought that since it might theoretically happen it would be nice to avoid the issue altogether. I suppose the trade off with performance and complexity isn't worth it after all.
About 64bit IDs, I thought I read on the manual that the KeyTable strategy internally used ints, so I didn't think that using longs was an option. That's good to know, thanks. |
|
|
|
|
Guk, you're right, the manual does say that. The manual is wrong: KeyTable internally uses longs. Thanks for drawing our attention to that, and apologies for the confusion: we'll get it fixed. That said, one area where KeyTable does use 32-bit integers is the default table definition. The KeyTable.sql script supplied with LightSpeed creates the KeyTable.NextId column as INT (or the equivalent on your database). To generate 64-bit IDs, you'll need to manually create or update the KeyTable schema to BIGINT (or equivalent). |
|
|
|
|
Rob: Check out this earlier thread... |
|
|
|
|
+1 support for imaginary numbers. But seriously, I can appreciate you would want to keep nice identifiers by closing down gaps in the keytable, re-allocating the identifiers to keep numbers low so they're easy to remember, things like that. It's just a considerable amount of work for such a small gain. |
|
|
|
