When is the id field set for single field identity with HighLow?

5 posts, 1 answers
  1. Peter
    Peter avatar
    23 posts
    Member since:
    Sep 2008

    Posted 16 Dec 2009 Link to this post

    Hi

    We're looking at switching from internal identity to single field identity (because we want access to the key value), but still using the HighLow key generator.  That's straightforward enough (well documented, thank you) and works fine for our routine scenarios.  However, we've hit a problem when we try to use the id of a new persistent object before committing it (it has been added to the scope): the id value is still zero (ie unset).  At first I thought this meant the ids weren't set until commit time, but checking later in the sequence (just before commit, in fact), I can see that the ids are getting set prior to commit.  My question is when does that happen?  (The Object Lifecycle documentation says that calling IObjectScope.Add makes the object state 'persistent new' and "...an object identifier is assigned to the object", but that isn't happening in our setup.)

    Experimenting via the debugger, I've found that getting the ObjectId for a new object causes its id to be set (and that may be why I'm seeing the ids close to the commit call - we use the ObjectIds for some book-keeping functionality that's happened by then).  I'll use that as a workaround, but it would be preferable to have a definite point at which the id is guaranteed to be set (and if that isn't the Add method, some way to force it).

    Best regards, Peter
  2. Damyan Bogoev
    Admin
    Damyan Bogoev avatar
    581 posts

    Posted 19 Dec 2009 Link to this post

    Hello Peter,

    While you have an active transaction you can call the IObjectScope.Transaction.Flush() method. It will flush all dirty and new instances to the database and evict all instances from the local cache. Thereby the identity value will be available before executing Commit() or Rollback().
    Hope that helps.

    Greetings,
    Damyan Bogoev
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
  3. DevCraft banner
  4. Peter
    Peter avatar
    23 posts
    Member since:
    Sep 2008

    Posted 12 Jan 2010 Link to this post

    Hello Damyan

    Thank you for the suggestion, but using ITransaction.Flush isn't appropriate in our scenario:
    • we would not want to send changes to the database at this point (we'd end up with db transactions being open for too long);
    • there's no natural place in our design to put such a call (the code that's using the id field doesn't look at the scope, never mind the transaction and I really don't want that code interacting with the transaction).
    I'd still like an answer to my original question(s): when is the id field set / what can I do ensure it has happened (without sending changes to the database).

    Best regards, Peter
  5. Answer
    Alexander
    Admin
    Alexander avatar
    727 posts

    Posted 14 Jan 2010 Link to this post

    Hello Peter,

    Unfortunately there is no other way at the moment except accessing the ObjectId which forces it to be loaded. Otherwise the id will be assigned when the transaction is committed.

    Greetings,
    Alexander
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
  6. Peter
    Peter avatar
    23 posts
    Member since:
    Sep 2008

    Posted 14 Jan 2010 Link to this post

    Thank you Alexander - we'll stick with accessing the ObjectId as a way of guaranteeing that the identity is set before we use it.
Back to Top
DevCraft banner