BreezeJS: Server added object showing as added in client after save changes - breeze

I have a breeze controller that adds an entity during the save changes that the client did not submit.
protected override bool BeforeSaveEntity(EntityInfo entityInfo)
{
if (entityInfo.Entity.GetType() == typeof(User))
{
if (entityInfo.EntityState == EntityState.Added)
{
User user = entityInfo.Entity as User;
OrganizationUser orgUser = new OrganizationUser()
{
Enabled = true,
OrganizationId = User.OrgId,
User = user
};
user.OrganizationUsers.Add(orgUser);
}
return true;
}
throw new InvalidOperationException("You can not use this service to modify an entity of type: " + entityInfo.Entity.GetType().Name);
}
When the response is returned the client side breeze manager sets the state of the server side added object as 'Added'. The OrganizationUser object above ends up with an Added state on the client. It then gets submitted in the next SaveChanges. Is this a bug?
Here is the response from the first save:
{
"$id": "1",
"$type": "Breeze.WebApi.SaveResult, Breeze.WebApi",
"Entities": [{
"$id": "2",
"$type": "LeonardoMD.Server.Api.Security.Admin.User, LeonardoMD.Server",
"Id": 9176,
"Email": "SearchProviderA#leonardoMD.com",
"FirstName": "SearchProviderA",
"LastName": "SearchProviderA",
"OrganizationUsers": [{
"$id": "3",
"$type": "LeonardoMD.Server.Api.Security.Admin.OrganizationUser, LeonardoMD.Server",
"UserId": 9176,
"User": { "$ref": "2" },
"OrganizationId": 421,
"Enabled": true
}]
}],
"KeyMappings": [{
"$id": "4",
"$type": "Breeze.WebApi.KeyMapping, Breeze.WebApi",
"EntityTypeName": "LeonardoMD.Server.Api.Security.Admin.User",
"TempValue": -1,
"RealValue": 9176
}]
}
Here is the submission of the second save:
{
"entities": [{
"Id": -2,
"CreateDate": null,
"CreateUserId": null,
"ModifyDate": null,
"ModifyUserId": null,
"Email": "SearchProviderB#leonardoMD.com",
"FirstName": "SearchProviderB",
"LastName": "SearchProviderB",
"BirthDate": null,
"GenderId": null,
"AddressLine1": null,
"AddressLine2": null,
"City": null,
"State": null,
"StateId": null,
"PostalCode": null,
"CountryId": null,
"DayPhone": null,
"DayPhoneExtension": null,
"Password": null,
"SecretQuestion": null,
"SecretAnswer": null,
"Enabled": null,
"AcceptTermsDate": null,
"entityAspect": {
"entityTypeName": "User:#LeonardoMD.Server.Api.Security.Admin",
"defaultResourceName": "Users",
"entityState": "Added",
"originalValuesMap": {},
"autoGeneratedKey": {
"propertyName": "Id",
"autoGeneratedKeyType": "Identity"
}
}
},
{
"UserId": 9176,
"OrganizationId": 421,
"Enabled": true,
"entityAspect": {
"entityTypeName": "OrganizationUser:#LeonardoMD.Server.Api.Security.Admin",
"defaultResourceName": "OrganizationUsers",
"entityState": "Added",
"originalValuesMap": {},
"autoGeneratedKey": null
}
}],
"saveOptions": {}
}
Notice the second entity is the entity returned in the response of the previous save changes. It's entityState is set to Added.
I have a work-around but its fragile and would need to be written special to every circumstance where the server returns a new entity after a save. Is there a way to set Breeze to acceptChanges on all new entities returned from the server as the the response to a saveChanges call?
manager.saveChanges()
.then(function (saveResult) {
$.each(saveResult.entities, function (i, entity) {
if (entity.organizationUsers && entity.organizationUsers().length > 0)
$.each(entity.organizationUsers(), function (index, orgUser) {
orgUser.entityAspect.acceptChanges();
});
entity.entityAspect.acceptChanges();
});
dfd.resolve();
})
.fail(function (error) { _this.handleError(context, promise, error); });

We were able to reproduce the problem and it is a bug. (The entity added on server should have returned to the client as an Unchanged entity)
We are working on a fix.
===EDIT===
The BeforeSaveEntity method is called once for each entity to be saved and should only manipulate the entity in question. You can find more about this at http://www.breezejs.com/documentation/custom-efcontextprovider.
If you want to create more entities to be saved in the server, you should do so in the BeforeSaveEntities method, where you can also add them to the saveMap dictionary to ensure they are saved in the DB.
i.e.
protected override Dictionary<Type, List<EntityInfo>> BeforeSaveEntities(Dictionary<Type, List<EntityInfo>> saveMap) {
Dictionary<Type, List<EntityInfo>> saveMapAdditions = new Dictionary<Type, List<EntityInfo>>();
var prod = this.CreateEntityInfo(product, EntityState.Added);
// add data to the entity
saveMapAdditions[typeof(Product)].Add(prod);
return base.BeforeSaveEntities(saveMap);
}

As of Breeze 1.3.5, available now, this has been fixed. and thanks for the repro...

Related

Rest Assured Post request erase previous data

I am using json-server and have a dummy json. When i am adding a new student (say id=100) using post request. Every time it erase previous student (id=14) and then create new student.
Below is the payload.
{
"data": {
"studname": null,
"student": [
{
"name": "JJJ",
"location": null,
"phone": null,
"courses": null,
"id": 14
}
]
}
}
Here is my rest assured code which i am running through eclipse:
#Test
public void addStudentData() {
StudentList Studentdetails = new StudentList();
StudentsDetails mainDetails = new StudentsDetails();
mainDetails.setName("JJJ");
mainDetails.setId(15);
List < StudentsDetails > details = new ArrayList < StudentsDetails > ();
details.add(mainDetails);
Studentdetails.setStudent(details);
given()
.contentType("application/json")
.body(Studentdetails)
.when()
.post(EndPoints.CREATE_STUDENTS)
.then()
.extract().response().asString();
}
output: Status 201
"data": {
"studname": null,
"student": [
{
"name": "James",
"location": null,
"phone": null,
"courses": null,
"id": 101
}
]
}

Owner_id field does not pass validation error. What is wrong with my schema?

I am looking into what is wrong with my schema. I'm attempting to insert an entry into my collection and I have gotten a slew of errors as I've changed things around but this seems to be the closest I have gotten to successfully inserting a document. I am using the mongodb-stitch-browser-sdk in a React Ionic project and I have a valid user logged in.
I am using the StitchUser.id which is a string as my owner_id (matches the id of my valid user in users collection).
Here is my schema followed by the error in Stitch logs. I was simply trying to insert a document to my Goals table. Also, there are no filters on this collection and there is only one role with the following rule.
{
"owner_id": "%%user.id"
}
This gives the user read and write permissions on the collection's that they created.
{
"bsonType": "object",
"required": [
"goalTitle",
"startDate",
"endDate",
"owner_id"
],
"properties": {
"_id": {
"bsonType": "objectId"
},
"owner_id": {
"bsonType": "string",
"validate": {
"%or": [
{
"%%prevRoot.owner_id": {
"%exists": false
}
},
{
"%%prevRoot.owner_id": "%%this"
}
]
}
},
"goalTitle": {
"bsonType": "string",
"minLength": {
"$numberInt": "1"
},
"maxLength": {
"$numberInt": "30"
}
},
"goalDescription": {
"bsonType": "string",
"minLength": {
"$numberInt": "0"
},
"maxLength": {
"$numberInt": "600"
}
},
"startDate": {
"bsonType": "string"
},
"endDate": {
"bsonType": "string"
}
}
}
Error:
role "owner" in "todo_list.Goals" does not have insert permission for document with _id: ObjectID("5e6aa8d11d233536e3ea8604"): could not validate document:
owner_id: Does not pass validation
Stack Trace:
StitchError: insert not permitted
Details:
{
"serviceAction": "insertOne",
"serviceName": "mongodb-atlas",
"serviceType": "mongodb-atlas"
}
{
"arguments": [
{
"collection": "Goals",
"database": "todo_list",
"document": {
"goalTitle": "Test Goal",
"goalDescription": "Test Description",
"endDate": "2020-03-11",
"startDate": "2020-03-10",
"owner_id": "5e6891382e6039c1c32f7d46",
"_id": {
"$oid": "5e6aa8d11d233536e3ea8604"
}
}
}
],
"name": "insertOne",
"service": "mongodb-atlas"
}
I've created another collection with no schema and the same rule checking for owner_id and documents in that collection are able to be inserted just fine. I'd have to imagine it is a schema error.

Get OData option set values and names

I am using odata api, now I have an attribute on an entity that is an option select like :
attribute name is : status
values are: 1, 2, 3
names: done, progress, new
the thing is when I am using postman to fetch metadata and all I get for the fields 'status' its that its type integer.
Question how do I fetchj option names and values from metadata so I get values and names in response ?
Currently I get this:
<Property Name="status" Type="Edm.Int32">
<Annotation Term="Org.OData.Core.V1.Description" String="" />
</Property>
But I want to get the value and names on response ?
This could be vastly simplified, assuming all you want are the int values, and names for a particular option set attribute of an entity:
GET [Organization URI]/api/data/v8.2/EntityDefinitions(LogicalName='contact')/Attributes(LogicalName='status')/Microsoft.Dynamics.CRM.PicklistAttributeMetadata?$select=LogicalName&$expand=OptionSet($select=Options),GlobalOptionSet($select=Options)
The $select=LogicalName is just so it doesn't return all the other metadata for the attribute, and the $expand=OptionSet($select=Options) is for local option sets, and the GlobalOptionSet($select=Options) is for Global. If you know what type it is, you can skip it the other, but if you are putting this logic in a shared library (you are aren't you?) then adding both won't hurt:
{
"#odata.context":"http://YourOrg.com/YourInstance/api/data/v8.2/$metadata#EntityDefinitions('new_entity')/Attributes/Microsoft.Dynamics.CRM.PicklistAttributeMetadata(LogicalName,OptionSet,GlobalOptionSet,OptionSet(Options),GlobalOptionSet(Options))/$entity",
"LogicalName":"new_familyshortname",
"MetadataId":"dc11c01f-b6bd-4664-82d0-3a521841c1f5",
"OptionSet#odata.context":"http://YourOrg.com/YourInstance/api/data/v8.2/$metadata#EntityDefinitions('new_entity')/Attributes(dc11c01f-b6bd-4664-82d0-3a521841c1f5)/Microsoft.Dynamics.CRM.PicklistAttributeMetadata/OptionSet(Options)/$entity",
"OptionSet":null,
"GlobalOptionSet":{
"#odata.type":"#Microsoft.Dynamics.CRM.OptionSetMetadata",
"Options":[
{
"Value":117280000,
"Label":{
"LocalizedLabels":[
{
"Label":"English Value 1",
"LanguageCode":1033,
"IsManaged":true,
"MetadataId":"3cb6bbd5-796f-e111-8cf3-3cd92b023782",
"HasChanged":null
},
{
"Label":"French Value 1",
"LanguageCode":1036,
"IsManaged":false,
"MetadataId":"d88be67d-4a7d-e411-8890-0050569f1654",
"HasChanged":null
}
],
"UserLocalizedLabel":{
"Label":"English Value 1",
"LanguageCode":1033,
"IsManaged":true,
"MetadataId":"3cb6bbd5-796f-e111-8cf3-3cd92b023782",
"HasChanged":null
}
},
"Description":{
"LocalizedLabels":[
{
"Label":"",
"LanguageCode":1033,
"IsManaged":true,
"MetadataId":"3db6bbd5-796f-e111-8cf3-3cd92b023782",
"HasChanged":null
}
],
"UserLocalizedLabel":{
"Label":"",
"LanguageCode":1033,
"IsManaged":true,
"MetadataId":"3db6bbd5-796f-e111-8cf3-3cd92b023782",
"HasChanged":null
}
},
"Color":null,
"IsManaged":true,
"MetadataId":null,
"HasChanged":null
},
... MORE ...
],
"MetadataId":"dcbbe460-bedb-4985-9a17-2f3dbc637594"
}
}
According to this article this is a multi-step process.
Please note that all the examples use HTTP GET.
First retrieve the entity's MetaData Id (for this example we're using the entity 'account'):
https://myOrg.crm.dynamics.com/api/data/v8.2/EntityDefinitions?$select=LogicalName,MetadataId&$filter=LogicalName eq 'account'
Returns:
{
"#odata.context": "https://myOrg.crm.dynamics.com/api/data/v8.2/$metadata#EntityDefinitions(LogicalName,MetadataId)",
"value": [{
"LogicalName": "account",
"MetadataId": "70816501-edb9-4740-a16c-6a5efbc05d84"
}]
}
Then retrieve the attribute's MetaDataId (in this example we're using the option set 'customertypecode'):
https://myOrg.crm.dynamics.com/api/data/v8.2/EntityDefinitions(70816501-edb9-4740-a16c-6a5efbc05d84)?$select=LogicalName&$expand=Attributes($select=LogicalName;$filter=LogicalName eq 'customertypecode')
Returns:
{
"#odata.context": "https://myOrg.crm.dynamics.com/api/data/v8.2/$metadata#EntityDefinitions(LogicalName,Attributes(LogicalName))/$entity",
"LogicalName": "account",
"MetadataId": "70816501-edb9-4740-a16c-6a5efbc05d84",
"Attributes#odata.context": "https://myOrg.crm.dynamics.com/api/data/v8.2/$metadata#EntityDefinitions(70816501-edb9-4740-a16c-6a5efbc05d84)/Attributes(LogicalName)",
"Attributes": [{
"#odata.type": "#Microsoft.Dynamics.CRM.PicklistAttributeMetadata",
"LogicalName": "customertypecode",
"MetadataId": "4e33af09-ba43-4365-a747-c7e4f9992172"
}]
}
Then query with the entity's and attribute's MetadataIds to get the option set values:
https://myOrg.crm.dynamics.com/api/data/v8.2/EntityDefinitions(70816501-edb9-4740-a16c-6a5efbc05d84)/Attributes(4e33af09-ba43-4365-a747-c7e4f9992172)/Microsoft.Dynamics.CRM.PicklistAttributeMetadata?$select=LogicalName&$expand=OptionSet
Returns (truncated at 2 values):
{
"#odata.context": "https://myOrg.crm.dynamics.com/api/data/v8.2/$metadata#EntityDefinitions(70816501-edb9-4740-a16c-6a5efbc05d84)/Attributes/Microsoft.Dynamics.CRM.PicklistAttributeMetadata(LogicalName,OptionSet)/$entity",
"LogicalName": "customertypecode",
"MetadataId": "4e33af09-ba43-4365-a747-c7e4f9992172",
"OptionSet#odata.context": "https://myOrg.crm.dynamics.com/api/data/v8.2/$metadata#EntityDefinitions(70816501-edb9-4740-a16c-6a5efbc05d84)/Attributes(4e33af09-ba43-4365-a747-c7e4f9992172)/Microsoft.Dynamics.CRM.PicklistAttributeMetadata/OptionSet/$entity",
"OptionSet": {
"MetadataId": "3629e642-b895-41ab-8f1d-ea5bfa30e992",
"HasChanged": null,
"IsCustomOptionSet": false,
"IsGlobal": false,
"IsManaged": true,
"Name": "account_customertypecode",
"ExternalTypeName": null,
"OptionSetType": "Picklist",
"IntroducedVersion": "5.0.0.0",
"Description": {
"LocalizedLabels": [{
"Label": "Type of the account.",
"LanguageCode": 1033,
"IsManaged": true,
"MetadataId": "73f68e38-c78d-48a5-80cb-bee895baab2b",
"HasChanged": null
}],
"UserLocalizedLabel": {
"Label": "Type of the account.",
"LanguageCode": 1033,
"IsManaged": true,
"MetadataId": "73f68e38-c78d-48a5-80cb-bee895baab2b",
"HasChanged": null
}
},
"DisplayName": {
"LocalizedLabels": [{
"Label": "Relationship Type",
"LanguageCode": 1033,
"IsManaged": true,
"MetadataId": "e5d47366-fd09-41e6-96a1-cbfdd113b932",
"HasChanged": null
}],
"UserLocalizedLabel": {
"Label": "Relationship Type",
"LanguageCode": 1033,
"IsManaged": true,
"MetadataId": "e5d47366-fd09-41e6-96a1-cbfdd113b932",
"HasChanged": null
}
},
"IsCustomizable": {
"Value": true,
"CanBeChanged": false,
"ManagedPropertyLogicalName": "iscustomizable"
},
"Options": [{
"Value": 1,
"Color": null,
"IsManaged": true,
"ExternalValue": null,
"MetadataId": null,
"HasChanged": null,
"Label": {
"LocalizedLabels": [{
"Label": "Competitor",
"LanguageCode": 1033,
"IsManaged": true,
"MetadataId": "6c54c2fa-2241-db11-898a-0007e9e17ebd",
"HasChanged": null
}],
"UserLocalizedLabel": {
"Label": "Competitor",
"LanguageCode": 1033,
"IsManaged": true,
"MetadataId": "6c54c2fa-2241-db11-898a-0007e9e17ebd",
"HasChanged": null
}
},
"Description": {
"LocalizedLabels": [],
"UserLocalizedLabel": null
}
},
{
"Value": 2,
"Color": null,
"IsManaged": true,
"ExternalValue": null,
"MetadataId": null,
"HasChanged": null,
"Label": {
"LocalizedLabels": [{
"Label": "Consultant",
"LanguageCode": 1033,
"IsManaged": true,
"MetadataId": "6e54c2fa-2241-db11-898a-0007e9e17ebd",
"HasChanged": null
}],
"UserLocalizedLabel": {
"Label": "Consultant",
"LanguageCode": 1033,
"IsManaged": true,
"MetadataId": "6e54c2fa-2241-db11-898a-0007e9e17ebd",
"HasChanged": null
}
},
"Description": {
"LocalizedLabels": [],
"UserLocalizedLabel": null
}
}
}
}

Breeze EntityManager cache not cleared after successful server save

I've been trying for a few days now to get the Breeze 1.4.9 to work with a rails back end in a different manner than the Breeze Ruby SPA sample. I would rather send bulk save changes instead of trying to send RESTful calls to the server on every entity change. To that end, I've written a rails controller/model methods that will parse out all the different entities in a Breeze SaveChanges POST and act accordingly. Everything works great except that the response to SaveChanges POST doesn't seem to satisfy all the checks for Breeze and EntityManager.hasChanges() is still true even after the response is processed successfully.
Here's a typical cycle:
Breeze requests my hand crafted metadata and parses it fine:
{
"metadataVersion": "1.0.5",
"namingConvention": "rubyNamingConvention",
"localQueryComparisonOptions": "caseInsensitiveSQL",
"dataServices": [
{
"serviceName": "breeze\/Breeze\/",
"hasServerMetadata": true,
"jsonResultsAdapter": "webApi_default",
"useJsonp": false
}
],
"structuralTypes": [
{
"shortName": "VarianceReason",
"namespace": "Icon",
"autoGeneratedKeyType": "Identity",
"defaultResourceName": "VarianceReasons",
"dataProperties": [
{
"name": "id",
"dataType": "Int32",
"isNullable": false,
"defaultValue": 0,
"isPartOfKey": true,
"validators": [
{
"name": "required"
},
{
"name": "int32"
}
]
},
{
"name": "name",
"dataType": "String",
"isNullable": false,
"defaultValue": "",
"maxLength": 256,
"validators": [
{
"name": "required"
},
{
"maxLength": 256,
"name": "maxLength"
}
]
},
{
"name": "createdAt",
"dataType": "DateTime",
"isNullable": false,
"defaultValue": "1900-01-01T08:00:00.000Z",
"validators": [
{
"name": "required"
},
{
"name": "date"
}
]
},
{
"name": "updatedAt",
"dataType": "DateTime",
"isNullable": false,
"defaultValue": "1900-01-01T08:00:00.000Z",
"validators": [
{
"name": "required"
},
{
"name": "date"
}
]
}
]
}
],
"resourceEntityTypeMap": {
"VarianceReasons": "VarianceReason:#Icon"
}
}
I make an entity change in Breeze and it POSTs the below to rails when I call em.SaveChanges():
{
"entities":[
{
"id":-1,
"name":"anyuthingasd",
"created_at":"1900-01-01T08:00:00.000Z",
"updated_at":"1900-01-01T08:00:00.000Z",
"entityAspect":{
"entityTypeName":"VarianceReason:#Icon",
"defaultResourceName":"VarianceReasons",
"entityState":"Added",
"originalValuesMap":{
},
"autoGeneratedKey":{
"propertyName":"id",
"autoGeneratedKeyType":"Identity"
}
}
}
],
"saveOptions":{
}
}
Rails then responds with:
{
"KeyMappings":[
{
"EntityTypeName":"VarianceReason:#Icon",
"TempValue":-1,
"RealValue":16
}
],
"Entities":[
{
"id":16,
"name":"anyuthingasd",
"created_at":"2014-05-02T14:21:24.221Z",
"updated_at":"2014-05-02T14:21:24.221Z",
"Entity":null
}
]
}
Breeze then merges in the new id key mapping but doesn't clear the cache, so next time I make another entity change it still has the first change which has already persisted to the server and the new change. Can anyone tell me what I'm not responding with from the rails side that makes Breeze EntityManager not satisfied? I'm trying to trace through the 15k lines of code but can't say I'm a JS ninja.
We really do need to show folks how to build a data service adapter for whatever service they've got.
In this case, it appears you chose to implement something like the SaveChanges method in C# on the Web API. In other words, you've chosen to emulate the out-of-the-box Breeze protocol. That's cool! And non-trivial too so kudos to you.
I think what's missing from the entity JSON in your save response is the EntityType name. Breeze can't find the corresponding cached entities without knowing their types and thus cannot update their change-states.
Again, because you've decided to use the default Web API data service adapter, you'll want to return a response that adapter expects. That adapter defines a "jsonResultsAdapter" that expects each JSON entity data object to have a $type property specifying the full type name (namespace.typename).
In your example, I think you'd want to return
...
"Entities":[
{
"$type": "Icon.VarianceReason",
"id":16,
"name":"anyuthingasd",
"created_at":"2014-05-02T14:21:24.221Z",
"updated_at":"2014-05-02T14:21:24.221Z",
}
]
How about an example?
I suspect that you may not have easy access to a server with Web API that can show you what a save response looks like with the default adapter. Therefore, I've pasted below a Todo app's saveChanges request and response for a change-set that includes a new, a modified, and a deleted TodoItem.
The Request
Below is the payload of the POST request to the "SaveChanges" endpoint. It is probably way more verbose than you need (more verbose than I'd need). Just to pick one example, the "autoGeneratedKey" is of no interest to the server whatsoever.
I'm just showing you what the default data service adapter sends. Someday you'll write your own to do it the way you want it. For now I suppose there is no harm in sending too much crappola ... as long as you're happy to ignore it on the Rails end :-)
{
"entities": [
{
"Id": 5,
"Description": "Cheese",
"CreatedAt": "2012-08-22T09:05:00.000Z",
"IsDone": true,
"IsArchived": false,
"entityAspect": {
"entityTypeName": "TodoItem:#Todo.Models",
"defaultResourceName": "Todos",
"entityState": "Deleted",
"originalValuesMap": {
},
"autoGeneratedKey": {
"propertyName": "Id",
"autoGeneratedKeyType": "Identity"
}
}
},
{
"Id": 6,
"Description": "Modified Todo",
"CreatedAt": "2012-08-22T09:06:00.000Z",
"IsDone": false,
"IsArchived": false,
"entityAspect": {
"entityTypeName": "TodoItem:#Todo.Models",
"defaultResourceName": "Todos",
"entityState": "Modified",
"originalValuesMap": {
"Description": "Wine"
},
"autoGeneratedKey": {
"propertyName": "Id",
"autoGeneratedKeyType": "Identity"
}
}
},
{
"Id": -1,
"Description": "New Todo",
"CreatedAt": "2014-05-02T17:34:00.904Z",
"IsDone": false,
"IsArchived": false,
"entityAspect": {
"entityTypeName": "TodoItem:#Todo.Models",
"defaultResourceName": "Todos",
"entityState": "Added",
"originalValuesMap": {
},
"autoGeneratedKey": {
"propertyName": "Id",
"autoGeneratedKeyType": "Identity"
}
}
}
],
"saveOptions": {
}
}
The Response
The $id property is a node counter. It's useful when you have repeated entities so you don't have to worry about cycles or repeated entity data in your payload (an object with a $ref property is the placeholder for the repeated entity). You can ignore $id if you don't need this feature (and you rarely would need it in a save result).
Notice that the $type is in the .NET "CSDL" type format "namespace.typename", not the Breeze type format "typename:#namespace". This is an artifact of the data service adapter's jsonResultsAdapter ... which you can change to better suit your Rails implementation. None of this is cast in stone. I'm just reporting what these adapters do as delivered.
You can ignore the assembly name (", Todo-Angular") in the $type value; Breeze doesn't care about it.
Notice that the deleted "Cheese" entity was returned with all of its contents. I bet you don't have to do that. You could get away with returning a stripped down version that simply lets the client know Rails got the message:
{
"$id": "2",
"$type": "Todo.Models.TodoItem, Todo-Angular",
"Id": 5
},
And now ... the complete JSON response body:
{
"$id": "1",
"$type": "Breeze.ContextProvider.SaveResult, Breeze.ContextProvider",
"Entities": [
{
"$id": "2",
"$type": "Todo.Models.TodoItem, Todo-Angular",
"Id": 5,
"Description": "Cheese",
"CreatedAt": "2012-08-22T09:05:00.000Z",
"IsDone": true,
"IsArchived": false
},
{
"$id": "3",
"$type": "Todo.Models.TodoItem, Todo-Angular",
"Id": 6,
"Description": "Modified Todo",
"CreatedAt": "2012-08-22T09:06:00.000Z",
"IsDone": false,
"IsArchived": false
},
{
"$id": "4",
"$type": "Todo.Models.TodoItem, Todo-Angular",
"Id": 7,
"Description": "New Todo",
"CreatedAt": "2014-05-02T17:34:00.904Z",
"IsDone": false,
"IsArchived": false
}
],
"KeyMappings": [
{
"$id": "5",
"$type": "Breeze.ContextProvider.KeyMapping, Breeze.ContextProvider",
"EntityTypeName": "Todo.Models.TodoItem",
"TempValue": -1,
"RealValue": 7
}
],
"Errors": null
}

Remove the certain properties of objects from the json document response Swagger for REST api

Hi I am using swagger for documentation of my RESTful web service. wanted to know is there any way to remove the certain properties of objects from the json document response? I mean there are lots of properties that swagger gives for my method param objects and response model (e.g. notes, defaultValue, allowableValue, internalDescription etc.) that are not required for me and are null due to that the response is not much readable
For method params:
"parameters": [
{
"name": "someName1",
"description": null,
"notes": null,
"paramType": "path",
"defaultValue": null,
"allowableValues": null,
"required": true,
"allowMultiple": false,
"paramAccess": null,
"internalDescription": null,
"wrapperName": null,
"dataType": "string",
"valueTypeInternal": null
},
{
"name": "someName2",
"description": null,
"notes": null,
"paramType": "query",
"defaultValue": null,
"allowableValues": null,
"required": true,
"allowMultiple": false,
"paramAccess": null,
"internalDescription": null,
"wrapperName": null,
"dataType": "string",
"valueTypeInternal": null
}
],
-=============================================================================
For response model classes
"SomeResponseClass": {
"required": false,
"name": null,
"id": "SomeResponseClass",
"properties": {
"instanceVariable1": {
"required": false,
"name": null,
"id": null,
"properties": null,
"allowableValues": null,
"description": null,
"notes": null,
"access": null,
"default": null,
"additionalProperties": null,
"items": null,
"uniqueItems": false,
"type": "Date"
},
"instanceVariable2": {
"required": false,
"name": null,
"id": null,
"properties": null,
"allowableValues": null,
"description": null,
"notes": null,
"access": null,
"default": null,
"additionalProperties": null,
"items": null,
"uniqueItems": false,
"type": "double"
}
}
your JSON mapper is not configured to ignore null properties. You can easily address this as follows:
#Provider
#Produces(MediaType.APPLICATION_JSON)
public class JacksonJsonProvider extends JacksonJaxbJsonProvider {
private static ObjectMapper commonMapper = null;
public JacksonJsonProvider() {
if(commonMapper == null){
ObjectMapper mapper = new ObjectMapper();
mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
mapper.setSerializationInclusion(JsonInclude.Include.NON_DEFAULT);
mapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
commonMapper = mapper;
}
super.setMapper(commonMapper);
}
}
Add this mapper to your scanning properties in the web.xml and the nulls will be gone.

Resources