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
|
I'm trying to insert data in three different tables. All the inserts are done with its own unit of work and they share the same lightspeed context. Currently this is what is happening 1. Insert data in table 1. Sets the Id column to 1. 2. Value for NextId in KeyTable data changes to 11 3. Insert data in table 2. Sets the Id column to 2. (My expectation was that the Id column for the second table would be 11) 4. Value for NextId in KeyTable data remains at 11 5. Insert data in table 3. Sets the Id column to 3. KeyTable remains unchanged.
The tables in which data is being inserted, already contains some test data. The Ids are some higher numbers and (at the moment) are not conflicting with the new Ids. As part of our test, we need some test data. However, we do not know the order in which a tester will create new items in the application. Is there a strategy for KeyTable data in this type of scenario ?
|
|
|
|
|
When LightSpeed allocates IDs from a KeyTable, it doesn't query and update the key table for every ID: instead, it acquires a block of IDs, and goes back to the database only when it's used up that block. This is more efficient because it avoids incurring a separate database round-trip for each and every entity. The default block size is 10, and this can be overridden using LightSpeedContext.IdentityBlockSize. So in your situation, the KeyTable is starting at 1; when the first ID is needed, LightSpeed grabs the ID block 1-10 and updates the KeyTable to 11; and the second and third items get IDs from the already-acquired block rather than incurring new queries. My advice for setting up your test environment would be to manually initialise the KeyTable to a value higher than any existing ID in the database. This ensures that the KeyTable will never return an ID that is already in use. I'm not sure I understand the question about the order in which a tester will create new items. If this is an acceptance test, where a user is interacting with your app, then the IDs shouldn't really matter -- they should be invisible to the user anyway. If it's a unit test where you're creating new entities, then IDs will be allocated in order as you add items to a unit of work -- but again the exact ID values shouldn't normally be important. (Note there may be gaps if other apps/tests are using the database at the same time.) If it's a unit test where you want to verify behaviour against known data, then I'd create a SQL script to populate your test database: the SQL script will include fixed IDs and your tests can rely on those. Does that help? |
|
|
|
|
Thanks, This explanation does help and solves my problem. I had slightly misunderstood the KeyTable. Also having the NextId higher than any test data Id eliminates any issues with testing.
Cheers
|
|
|
|
