A Breeze EntityMananger is throwing an exception when I try to save two related entities. The exception is being thrown client-side before any communication happens with the server. The error message in the exception is "Validation error", but calling EntityAspect.getValidationError() on each entity listed in the exception returns an empty array.
The screenshot below shows a live example:
Question: Is there some other way of finding out what exactly the validation problem is or is this a bug?
Thanks for your time!
I found the cause of the behavior. rejectChanges() is called on the EntityManager for the entities in question before the exception raised by saveChanges() is rethrown, to be handled by the code in the example above. The error state of the entities is not preserved in the exception object, so calling getValidationErrors() on each entity after calling rejectChanges() returns an empty array since at that point the changes have been rolled back and there technically aren't any errors on the entity.
So, technically not a bug. Breeze is working as designed. However, I think there's an argument to be made that the exception object passed when saveChanges() fails should contain a complete and immutable description of the problem(s) that caused the exception.
Related
We are using breeze.js with entity framework to initiate client side entity management.
We randomly get "Failed to set the ‘$visited’ property on ‘DOMStringMap’: ‘data-$visited’ is not a valid attribute name" error the the breeze.js from __toJSONSafe method of it.
does anybody have any idea what could make "obj._$visited" property undefined? It is coming up as undefined and that is causing the issue during call to the saveChanges()
I'm guessing ... it seems like you've added some kind of DOM object to the entity before saving it. I can't imagine how else you could be subjecting the DOMStringMap to __toJSONSafe.
Would need to know more precisely what object (and entity) is involved when you get this exception.
You say it happens randomly. That doesn't make it easy on any of us. If you can make it happen often enough to detect, you could patch the __toJSONSafe method in your local copy of breeze.debug.js so that you can better trap the error and the information about what makes it happen.
Come back and share that information with us.
We have a controller where we are trying to carry out search on a domain class. The actual search logic is handled in a service. This search involves use of SomeDomain.withCriteria, fetchMode set to SELECT and createAlias. The search comes back fine with the required results. Once we have the results we redirect to another action in the same controller which handles results. Returning from a controller flushes the session and this is where the controller throws the following exception:
object references an unsaved transient instance - save the transient
instance before flushing
Well it appears as somehow and somewhere in our code a domain object is created and is never saved. The error message is kind enough to show the type of the transient object but it does not inform where and when was it created. This remains a mystery that where this object is created from and I am now looking for ways to get hold of a reference to this object. So my question here is that how can I find all objects which are in a transient state?
I want the reference of this mystery unsaved object just because I want to call discard on it and see how things go on from there. I know that I don't need this object so if it is hanging around somewhere I want to discard it so that it does not end up in throwing exceptions. If someone can also figure out why and where that object gets created then that would be great.
We've had this problem too, and it can be an obnoxious bug to find. Presumably it's possible to find all transients by walking through Hibernate's internal structures, but I've never gone very far into it. Instead, we typically debug via flush() and binary search: flush the session more and more aggressively until it's obvious which operation introduced a transient to your object graph.
Having problem with inserting a model to database with EF in a MVC application.
Im receiving following error when callning dbContext.SaveChanges() :
[DbEntityValidationException: Validation failed for one or more entities. See 'EntityValidationErrors' property for more details.]
Any clue what this can be about?
Its strange because sometimes it works to make one insert but if i make another immediately after it crashes.
And sometimes it crashes on first insert.
You can check the accepted answer in this post: Validation failed for one or more entities. See 'EntityValidationErrors' property for more details
PS: Please remove error message details as it's of no use and it can expose private information.
More than likely you have some property on the entity that is not nullable. Most of the time when I get this error, that's the culprit. Set a watch on the 'EntityValidationErrors' property, then in the debugger expand into this property and you will see the exact message that is being thrown.
I created a Service Object (http://railscasts.com/episodes/398-service-objects), which basically creates two models, A and B, sets up the association between them where B belongs to A, and returns A (which in turn you can access B via A given the association).
On error, I return a hash with the error information. As I'm trying to test this method, I'm having an issue now where there are two possible types of returns: either a model (when it passes) or a hash with the error information.
Is this a signal that the design is wrong? I know when you test first (TDD) you avoid such design issues.
If it is an issue, then I know I would need to return an invalid A model. Assuming the model B throws an error on create, how would I still be able to return an invalid A model?
If returning an error hash is okay, how else can I design this method to be testing friendly?
Good insight and good question. :-) On the face of it, this seems like a good situation to raise a Ruby exception for the "error" case rather than returning as a hash as a result of the method call. You can define your own error class (probably should be a subclass of StandardError) and include the hash or whatever information you want as part of the error you raise. See http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_exceptions.html for a discussion of this general topic.
As for checking for the raising of errors in rspec, see the last answer to How to use RSpec's should_raise with any kind of exception?, including links to additional information.
If you want to present your API as a RESTful interface, the consensus seems to be to utilize the HTTP response codes to be to present exceptions, as discussed in How to handle REST Exceptions? If you do use the exceptional response codes (e.g. 40X) for presenting your exceptions, then the fact that you return a hash in that case and a model in the other case is not a bad smell, imho, as there is no expectation of consistency between the data that accompanies an error and the data that accompanies a successful return. In any event, I don't think returning an "invalid" model in the error case makes any sense, assuming you're not in fact creating/persisting the model in that situation.
You can test the type of result.
In rspec...
expect(actual).to be_an_instance_of(expected)
expect(actual).to be_a_kind_of(expected)
The Optimistic ConcurrencyException is not returned right. I tested this with the breeze ToDo sample and my app.
This is what is returned if i provoke a an OptimisticConcurrencyException:
{"$id":"1","$type":"System.Web.Http.HttpError, System.Web.Http","Message":"An error has occurred."}
The ExceptionType is missing. In debug-mode in VS this works right.
#sascha - You beat me to it on the <customErrors> thing which works fine if you're running in IIS (see Jimmy Bogard's alternative if you are one of the very few who would self-host your Web Api).
But I’m pretty sure it is the wrong thing to do ultimately. It is expedient for now but, as Jimmy says in his post, “It’s likely not something we want in production.” An app shouldn’t expose unfiltered exceptions to the client for routine stuff like optimistic concurrency or validation errors.
I intend to find a better approach, most likely involving the HttpResponseException as described here. I'll give strong consideration to a “Custom Exception Filter” for dealing with unhandled exceptions in a controlled manner.
I don’t think that approach is something that belongs in Breeze itself. It strikes me as requiring an application specific solution … one that knows which exceptions should be exposed and how they should be phrased. But the mechanism would be good to teach. Once you know how to do it, you can roll your own custom exception handling ... and leave the Web.config alone.
Hoping to write this guidance soon. Feel free to beat me to it :)
Hm..., when I attempt a concurrency exception in my test cases.
// assuming this causes a concurrency exception
em.saveChanges().then(
).fail(function(error) {
// error object detailed below
})
I get the following returned with the 'error' parameter
error.message: "Store update, insert, or delete statement affected an unexpected number of rows (0). Entities may have been modified or deleted since entities were loaded. Refresh ObjectStateManager entries."
error.responseText: {"$id":"1","$type":"System.Web.Http.HttpError, System.Web.Http","Message":"An error has occurred.","ExceptionMessage":"Store update, insert, or delete statement affected an unexpected number of rows (0). Entities may have been modified or deleted since entities were loaded. Refresh ObjectStateManager entries.","ExceptionType":"System.Data.OptimisticConcurrencyException","StackTrace":" at System.Data.Mapping.Update.Internal.UpdateTranslator.ValidateRowsAffected(Int64 <... more here ...> }
error.detail: < an even more detailed error object
error.detail.ExceptionType: "System.Data.OptimisticConcurrencyException"
There are other properties but these are the important ones.
I wonder what we are doing differently?