|
Hi, I created several entities that incorporate an Long Id. As i suspect a table is generated for this Keys (Int64-Generator). Every entity that uses this key type gets from this table a unique id (Long). Am i suspecting correct? If yes then maybe the long runs out faster? Updated at 20.10.2009 21:09:26hi alex, example. entity a has 100 rows in db. (id 1-101) the next should be 101. in the meantime entity b inserts 100 rows and gets id 102-202. entity a inserts 100 rows and gets id 203-304. and so on... now if i had 100 such entities the the ids will run out faster than if the table had a identity column. hope this helps... This thread was imported from our support forum. The original discussion may contain more detailed answer. Original topic by mantzas. |
|
See the log here: http://blog.alexyakunin.com/2009/10/v41 ... ching.html There is a part showing how default KeyGenerator works: Session 'KeyGenerator, #3'. Beginning transaction @ ReadCommitted. Session 'KeyGenerator, #3'. SQL batch: INSERT INTO [dbo].[Int32-Generator] DEFAULT VALUES; SELECT SCOPE_IDENTITY(); Session 'KeyGenerator, #3'. Commit transaction. So everything is pretty simple. We get keys in bulks (by 128 at once by default) in a special Session. Note that the last line there showing there was a bug when the test was running: actually there must be Rollback transaction ;) AFAIK this is already fixed in our repository. Ah, this... 1) The number of types is finite. Likely, 2000 is close to real-life maximums we know. So in worst case the whole range will be 2000 times smaller. 2) You must count hierarchies, not types. 3) Normally only a small subset of types are changed frequently (i.e. their new instances are added). In fact, you must count just "fast growing" hierarchies. So I suspect this will lead to reduction of this factor to ~ 100 even for very large system. But actually all this stuff does not matter at all... Since it will take ~ 10M years to overflow 2^63 range with ~ 30000 entities per second insertion speed ;) Note that normally it does not matter to how many tables you insert the data - 100 or 1. Or ~ 1 day for 2^31 (Int32) range. Ok, speaking seriously, it's pretty easy to assign your own KeyGenerator to a particular hierarchy instead of default one. Dmitri Maximov will shortly cover this topic. And about true IDENTITY columns: we WILL support them as possible key generators in near future. But their usage will lead to much slower insertion speed: currently we assign key on Entity creation (and that's really cool - you can be sure it won't change in any case), and we'll do the same in this case as well. But to create next key in this case, we must insert and remove "dummy" row. This will reduce Entity creation performance at least by ~ 3 times. This isn't good, but I think this is acceptable trade if you really need this for compatibility reasons. |
Yes, everything is correct.
> If yes then maybe the long runs out faster?
Err... What do you mean? I haven't understood this part.