I am a bit confused by this message sent by Xcode:
Setting the No Action Delete Rule on Passenger.taxi is an advanced setting [5]
These are the specifications
When I delete a Taxi instance, it should also delete all its Passenger instances. Current Delete Rule: Cascade
When I delete a Passenger instance, it should just delete that particular instance. Even if it is the last Passenger instance of a Taxi instance. A Taxi can exist without Passengers (1:mc). Current Delete Rule: No Action
What delete rule do I need here to meet the requirements?
Set the delete rule to nullify, which simply nils out the link. "No Action" is a bit weird in that you can think of it as leaving a pointer that does not really exist I'm not sure if that's what it would really do).
Related
I want to "reset" certain data in my database tables using a RESTful method but I'm not sure which one I should be using. UPDATE because I'm deleting records and updating the record where the ID is referenced (but never removing the record where ID lives itself), or DELETE because my main action is to delete associated records and updating is tracking those changes?
I suppose this action can be ran multiple times but the result will be the same, however the ID will always be found when "resetting".
I think you want the DELETE method
I have a collection of items and some of them may or may not be deleted, depending on some preconditions. If a user wants to delete a resource (DELETE /collection/1) and there are external dependencies on that resource, the server will return an error. But what should happen if the user wants to delete the entire collection (DELETE /collection)?
Should all the resources which can be deleted be deleted and the server return a 2xx, or should the server leave everything intact and return a 4xx? Which would be the expected behavior?
As a REST API consumer, I'd expect the operation to be atomic and maybe get back a 409 Conflict with details if one of the deletes fails. Plus the DELETE method is theoretically idempotent as #jbarrueta pointed out.
Now if undeletable resources is a normal event in your use case and happens frequently, you may want to stray from the norm a little bit, delete all that can be deleted and return something like a 206 Partial Content (don't know if that's legal for DELETE though) with details about undeleted resources.
However, if you need to manage error cases finely, you might be better off sending separate DELETE commands.
I think the proper result is 204 no content by success and 409 conflict by failure because of the dependencies (as the others pointed out). I support atomicity as well.
I think you are thinking about REST as SOAP/RPC, which it is clearly not. Your REST service MUST fulfill the uniform interface constraint, which includes the HATEOAS interface constraint, so you MUST send hyperlinks to the client.
If we are talking about a simple link, like DELETE /collection, then you must send the link to the client, only if the resource state transition it represents, is available from the current resource state. So if you cannot delete the collection because of the dependencies, then you don't send a link about this transition, because it is not possible.
If it is a templated link, then you have to attach the "removable" property to the items, and set the checkboxes to disabled if it is false.
This way conflict happens only when the client got the link from a representation of a previous (stale) resource state, and in that case you must update the client state by querying the server again with GET.
Another possible solution (ofc. in combination with the previous ones) to show the link and automatically remove dependencies.
I guess you can use PATCH for bulk updates, which includes bulk removal, so that can be another solution as well.
I'd say it depends on your domain (although I'd rather use DELETE /collection/all instead of DELETE/collection/),
When you have the situation where you use delete all but some items can't be deleted, it depends on your domain where if you are doing the delete all to free up resources where if not your business process suffers, then it's better to delete what can be deleted and put other into a retry queue makes sense. in that case response should be OK.
Also situations could arise where there could be two operations
Clean Up - only delete unused
Delete All - delete all
In either situation I'd rather use specific method rather than using DELETE on the root URL,
for Clean Up - DELETE /collection/unused
for Delete ALL - DELETE /collection/all
I'm working on a REST-like API.
This API have a this for changing a existing resource by ID:
/api/v1/admin/member/:ID
I any normal circumstances this would of course be a PUT when changing a resource.
But because of a compromise leading to simpler code, this route actually first delete the resource completely (and all references to it) and then create a new one based on the input given by a form.
In all means this will look and give the same end result as a resource change.
Question: Should this route be a PUT or a POST
The expected behavior is idempotent so I would say use PUT, and I would make sure the update occurs in a transaction so an error between deleting and inserting would not leave the resource deleted.
When a user unknowingly attempts to delete an entity that has children it fails because breeze does not currently support cascading deletes, which is expected.
But a side effect of this action is that it detaches entities from the local cache. So from the user interface it appears that those entities have been deleted.
Is this expected behavior?
Is there a straight forward way of checking if the entity has children (ex. hasChildren()) and prevent the user from getting into this state on the client side?
Is this an expected behavior?
Yes it is. When you delete a row. logically, it should disappear from the user's point of view, even though it may fail during the save. Any failure can be avoided by handling it in the savechanges fail method.
Is there a straight forward way of checking if the entity has children (ex. hasChildren()) and prevent the user from getting into this state on the client side?
Yes there is..
Let's say you have a parent "customer" and it's children "orders"
your code may be something like this:
if (customer.orders()) return 'Your message';
else
return customer().entityAspect.setDeleted();
However, I agree with PW Kad.. I would go for the the database choice and sit back.
If you are using SQL server then you might want to set a delete cascade rule from there.
For the sake of customer-orders, expand "orders" table; you'll find the FK constraint under "Keys".Right Click then Modify. a dialog will show; expand "Insert and Update specification"change the "Delete Rule" to "Cascade" You can set the update rule as well..
0x80040237 Cannot insert duplicate key.
I'm trying to write an import routine for MSCRM4.0 through the CrmService.
This has been successful up until this point. Initially I was just letting CRM generate the primary keys of the records. But my client wanted the ability to set the key of a our custom entity to predefined values. Potentially this enables us to know what data was created by our installer, and what data was created post-install.
I tested to ensure that the Guids can be set when calling the CrmService.Update() method and the results indicated that records were created with our desired values. I ran my import and everything seemed successful. In modifying my validation code of the import files, I deleted the data (through the crm browser interface) and tried to re-import. Unfortunately now it throws and a duplicate key error.
Why is this error being thrown? Does the Crm interface delete the record, or does it still exist but hidden from user's eyes? Is there a way to ensure that a deleted record is permanently deleted and the Guid becomes free? In a live environment, these Guids would never have existed, but during my development I need these imports to be successful.
By the way, considering I'm having this issue, does this imply that statically setting Guids is not a recommended practice?
As far I can tell entities are soft-deleted so it would not be possible to reuse that Guid unless you (or the deletion service) deleted the entity out of the database.
For example in the LeadBase table you will find a field called DeletionStateCode, a value of 0 implies the record has not been deleted.
A value of 2 marks the record for deletion. There's a deletion service that runs every 2(?) hours to physically delete those records from the table.
I think Zahir is right, try running the deletion service and try again. There's some info here: http://blogs.msdn.com/crm/archive/2006/10/24/purging-old-instances-of-workflow-in-microsoft-crm.aspx
Zahir is correct.
After you import and delete the records, you can kick off the deletion service at a time you choose with this tool. That will make it easier to test imports and reimports.