Collapsed Records in offline scenario

[henda79]

@adrianhall , I recall a conversation we had sometime ago and you explained Collapsed Records ?

On the server side, I'm using tables with FK's to ensure integrity, so as you know, I have to send the tables in order which up to now had worked. However the collapsed records feature make a mess of the order and fails with an exception on the server due to the violated FK.

Is there a way to disable the Collapsed Records feature ?

[adrianhall]

There is no way to disable collapsing records.

One of the things you need to be aware of is that updates are written as they arrive. If you have two writes to two different tables, then they are written individually without the benefit of transactions. As a result, establishing FK's to enforce integrity checks will inevitably fail at some point. It gets worse when you enable parallel writes, but it can happen at any time.

If you are relying on UpdateA happening before UpdateB, then collapsing records don't change the ordering EXCEPT if parallel writes are turned on. In that case, UpdateA and UpdateB can be sent to the server in two different threads. If UpdateB is "smaller" than UpdateA, it will be transmitted quicker, and will likely run first.

[henda79]

Thanks for your input. Unfortunately, I'm only one dev tasked with the whole project and my knowledge in not 100% in all areas. Your solution is similar to workarounds I was thinking but I think it would be complex to implement.

How do you enable/disable FK's from the client side ?
When we have a "sync conflict" due to an FK we get a Server Error 500 on the client and no information about it. I have very limited knowledge when it comes to ASP dev.

[adrianhall]

A server error 500 is generic "An exception was thrown that we don't know about". Obviously, I'd need the full exception in order to diagnose the issue.

[henda79]

Sorry, I was not clear. I know the error is due to the FK violation on the server side as I can see the logs on the console, but the client just gets back a 500, with no real meaning. Is there anyway to enhance this for the client.

[adrianhall]

Write an exception filter for the database errors. You can find an example here: https://github.com/Azure/azure-mobile-apps/blob/main/sdk/dotnet/src/Microsoft.AspNetCore.Datasync/Filters/DatasyncExceptionsAttribute.cs In your filter, you can adjust the response any way you want to. Make sure you are scoping the exception filter to only handle the errors you need to. (For example, the Datasync service has a HttpException as a core exception that it captures and it ignores all other exceptions). For example, you can produce a JSON payload for the message and associated information. You should NOT use a HTTP response code that the client SDK uses (400 would be a good one to use, since that's just Bad Request and is generally passed on to the client application).

Then apply your exception filter as an attribute to your controllers to install it.

[henda79]

Thanks Adrian, I'll take a peek.