0

I'm using Entity Framework 6 as my ORM for talking to a SQL Server database. I have two scenarios when inserting new records:

  1. The GUID of the record is empty, in which case I add the attribute

    DatabaseGenerated(DatabaseGeneratedOption.Identity)]

    above my ID fields on my POCOs, and the database happily generates a new sequential GUID for my record.

    This scenario is best for indexing. My client first talks to an API which tries to insert a record into the database and have the database generate a sequential GUID.


  1. The GUID of the record is already set, in which case that GUID should be set in the database. However, EF ignores this, and asks the database to generate a new sequential GUID anyway.

    This scenario is in case the client is offline or otherwise can't reach the API. In this case, it will persist data locally with its own generated GUID, and then try and save that to the database later.

I've done some searching and can't seem to find any way to only conditionally ask the database to generate a new GUID if one isn't already set. Is this possible?

Thanks!

derf26
  • 862
  • 1
  • 7
  • 16
  • Duplicate: http://stackoverflow.com/q/40598817/861716 – Gert Arnold Nov 16 '16 at 20:00
  • If you won't find a better way, one option is to generate sequential guid yourself (for example: http://stackoverflow.com/q/211498/5311735) – Evk Nov 17 '16 at 06:45

2 Answers2

0

Yes. Use method AddOrUpdate of EF

See AddOrUpdate

Luan_Nunes
  • 11
  • 3
  • I've tried this just now. Didn't really have much detail to go on but I did some research on how to use the method. It doesn't seem to be working though. – derf26 Nov 16 '16 at 19:18
  • Can you explain how AddOrUpdate would help? This is a link-only answer that's likely to be removed by the review process. – Gert Arnold Nov 18 '16 at 18:57
0

You cannot have both at the same time. In this case you are configuring EF to let the database create a new ID every time a record is inserted and EF will always do that. When a record is tracked as an insert it will always follow this behavior.

You need a way to track what entities were not able to reach the server to be inserted, and when the client application is online is able to sync the changes.

I would create a different local data relationships that would allow tracking the entities in your local storage. It takes a little more effort but it's worth the effort.

Arturo Martinez
  • 3,737
  • 1
  • 22
  • 35
  • I was thinking one way of doing it would be to have all the locally stored relationships work through a local GUID, say "LocalTransactionId", and have a separate (unique but can be null and not a primary key) GUID that is assigned by the server, called "ServerTransactionId". If the record can be inserted in the server's database successfully, then the two will be set to be the same, if not, then they will be different. Regardless, the local ID is used by EF for handling all the local relationships, and the server ID is used by the client to communicate with the API/Server. Thoughts? – derf26 Nov 17 '16 at 11:23
  • In the above example, the server would only ever know about the ServerTransactionId, whereas the client would hold both a LocalTransactionId and a ServerTransactionId. – derf26 Nov 17 '16 at 11:24
  • That could be a way to achieve it. Remember you don't want to dirty your server entities with properties that don't make any sense on the server side. Find a way in your deserialization to remove them. – Arturo Martinez Nov 17 '16 at 14:02