Referencing in-memory Entities after Commit

Posts   
 
    
Arif
User
Posts: 29
Joined: 01-Dec-2005
# Posted on: 27-Dec-2005 17:20:56   

When I try to access an in-memory instance of an entity, it gives me an ORMEntityOutOfSyncException with an error msg:


The entity is out of sync with its data in the database. Refetch this entity before using this in-memory instance.

This is after I have called the Commit on the underlying Collection to persist it to db. Everytime I save changes on my grid, will I need to refetch from DB so that I can manipulate that entity in code?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 27-Dec-2005 17:23:51   

Yes, though you can specify when you add the collection to the UnitOfwork if you want to refetch after save or not, so it's done for you automatically during the commit.

Frans Bouma | Lead developer LLBLGen Pro
Arif
User
Posts: 29
Joined: 01-Dec-2005
# Posted on: 27-Dec-2005 18:13:20   

Thats what i am doing with the additional params to AddCollectionForSave().


uow.AddCollectionForSave(hierTypeColl,true,true);
uow.Commit(adapter, true);

After the above code, when I try to iterate through the hierTypeColl, my recently saved entity in this collection is out-of-sync.

I have one more question on the architecture. If I have a supertype - subtype relation where the PK of the supertype is auto-assigned by the db and that same PK is also the PK of the subtype (i.e. the FK on the subtype also is the PK for the subtype). If I were to persist a new subtype entity (filling in values for supertype & subtype fields other than the PKs) would LLBLGen be able to create the supertype first & then use the db assigned PK of the supertype to insert as the PK of the subtype. Or is there a better way to do this in my case. P.S. Not sure if it matters here but, the auto-assigned value of the supertype PK is the newsequentialid() function.

Schema:

Object (ObjectGuid PK - db assigned) Employee (EmployeeGuid PK, FK - not assigned by db)

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 27-Dec-2005 18:46:24   

I think the usage of newsequentialid() is the problem. As the PK doesn't have a value, when it is saved, and currently newsequentialid() isn't supported, the PK doesn't get a value when the entity is actually saved, which means that a refetch doesn't work. Could you please check if the entity which is outofsync does have a PK set in the db with newsequentialid() and after the commit the PK value is still an empty GUID ?

Frans Bouma | Lead developer LLBLGen Pro
Arif
User
Posts: 29
Joined: 01-Dec-2005
# Posted on: 27-Dec-2005 19:08:19   

You are right. The entity is not being refetched properly and the Guid PK property is an empty Guid. But it is inserting the new row & the key field is getting assigned ok in the db. I even changed the db default to newid() and yet it wont refetch the entity after the insert.

Will it not fetch defaults unless they are identities?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 27-Dec-2005 20:32:56   

Arif wrote:

You are right. The entity is not being refetched properly and the Guid PK property is an empty Guid. But it is inserting the new row & the key field is getting assigned ok in the db. I even changed the db default to newid() and yet it wont refetch the entity after the insert.

NewID() has the same drawback: it's impossible to read back the inserted value.

Will it not fetch defaults unless they are identities?

Exactly, defaults for PK's arent read back unless they're identities. For guid's set the PK in code, using Guid.NewGuid() for now, till newsequenceid() is supported in v2.0 of llblgen pro.

Frans Bouma | Lead developer LLBLGen Pro