I have a view model that will always create a new entity (Score); it doesn't need to wait for nor query the repository to know this.
I (currently) want to create the new entity as the page loads and use it to populate the (KnockoutJS) view model.
I believe that the entity manager lazily populates the metadata and have spoofed the behavior I want by making an unnecessary query purely to force the metadata population. The API docs don't cover this:
http://www.breezejs.com/sites/all/apidocs/classes/EntityManager.html#property_metadataStore
Question
Is there a way to force the manager to populate the metadata without issuing a redundant query?
Here's the spoofed code flattened to show its intent:
manager.executeQuery(redundantQuery).then(function(data) {
var viewScore = manager.metadataStore.getEntityType("Score").createEntity();
viewScore.ID(breeze.core.getUuid());
viewScore.Value(57);
ko.applyBindings(viewScore, $ViewScore);
}).fail(function(e){
...
})
I'd be happy with:
manager.metadataStore.then(function() {
})...
Okay, lesson learned.... try it before asking.
This actually works:
manager.metadataStore.fetchMetadata(manager.dataService).then(function () {
var viewScore = manager.metadataStore.getEntityType("Score").createEntity();
viewScore.ID(breeze.core.getUuid());
viewScore.Value(57);
ko.applyBindings(viewScore, $ViewScore);
}).fail(function (e) {
...
});
My only remaining question is why is it necessary to pass the manager.dataService?
A single MetadataStore can store metadata for multiple DataServices. The manager.dataService is simply the 'default' DataService for an EntityManager, there may be others.
Related
I am playing around with a OData service and I am very confused when to use this
var oModel = new sap.ui.model.odata.ODataModel("proxy/http/services.odata.org/V3/(S(k42qhed3hw4zgjxfnhivnmes))/OData/OData.svc");
this.getView().setModel(oModel);
vs
var oModel = new sap.ui.model.odata.ODataModel("odatserviceurl", true);
var productsModel = new JSONModel();
oModel.read("/Products",
null,
null,
false,
function _OnSuccess(oData, response) {
var data = { "ProductCollection" : oData.results };
productsModel.setData(data);
},
function _OnError(error) {
console.log(error);
}
);
this.getView().setModel(productsModel);
I have two working example using both approach but I am not able to figure out why using read method if I can achieve same with first version. Please explain or guide me to the documentation which can clear my confusion.
Ok, lets start with the models:
JSON Model : The JSON model is a client-side model and, therefore, intended for small datasets, which are completely available on the client. The JSON model supports two-way binding. NOTE: no server side call is made on filtering, searching, refresh.
OData Model : The OData model is a server-side model: the dataset is only available on the server and the client only knows the currently visible rows and fields. This also means that sorting and filtering on the client is not possible. For this, the client has to send a request to the server. Meaning searching/filtering calls odata service again.
Now, lets look at scenarios where we will use these models:
Scenario 1: Showing data to user in a list/table/display form. Data manipulation is limited to searching and filtering. Here, I would use oData model directly to controls as only fetching of data is required.( your method 1) (NOTE: One way binding). Remember here all changes require a call to server.
Scenario 2: I have an application which has multiple inputs, user can edit changes, also some fields are calculated and mandatory. All in all, many user changes are done which may be temporary and user might not want to save them. Here, you dont want to send these temporary changes to backend as yet. You way want to manipulate, validate data before sending. Here, we will use JSON Model after reading data from odata model ( your method 2). Store the changes in local JSON model, validate and manipulate them and finally send the data using Odata create/update. Remember here all changes DO NOT require a call to server as data is present in local JSON MODEL.
Let me know if this helps you. :)
EDIT : Additional Information :
As per your comment :
Documentation says oModel.read' trigger get request but new sap.ui.model.odata.ODataModel("proxy/http/services.odata.org/V3/(S(k42qhed3hw4zgjxfnhivnmes))/OData/OData.svc")` does the same thing so why and when to use oModel.read
Here, is where you misunderstood. The code
new sap.ui.model.odata.ODataModel("proxy/http/services.odata.org/V3/(S(k42qhed3hw4zgjxfnhivnmes))/OData/OData.svc") will NOT send a read/get Request. It calls the odata services and fetches the metadata of the service. A service can have multiple entities.
For example: the service :http://services.odata.org/Northwind/Northwind.svc/ has mutiple entity sets such as Categories, Customers, Employees etc. So, when I declare : new sap.ui.model.odata.ODataModel("http://services.odata.org/Northwind/Northwind.svc/") it will fetch the metadata for service (not actual data). Only when you call the desired entity set, it will fetch the data. The Entity set is specified :
When you call the read method ( like you have specified '/Products')
Bind the entity set name directly to control like to List,Table etc ( items='{/Products}' )
I have two Relay mutations that I'm nesting to first add an object then set its name. I believe what I'm passing to the second mutation is in fact data fetched by Relay, but it appears to disagree with me. The code in the React view is as follows:
Relay.Store.update(
new AddCampaignFeatureLabelMutation({
campaign: this.props.campaign
}),
{
onSuccess: (data) => {
Relay.Store.update(
new FeatureLabelNameMutation({
featureLabel: data.addCampaignFeatureLabel.featureLabelEdge.node,
name: this.addLabelInputField.value
})
);
},
onFailure: () => {}
}
);
This does work, but gives me a warning:
Warning: RelayMutation: Expected prop `featureLabel` supplied to `FeatureLabelNameMutation` to be data fetched by Relay. This is likely an error unless you are purposely passing in mock data that conforms to the shape of this mutation's fragment.
Why does Relay think the data isn't fetched? Do I maybe need to explicitly return the new featureLabel in the payload somehow?
I ran into the same problem and it took me some time to figure out what was going on, so this might help others:
As the warning says, you have to provide an entity to the mutation that was fetched by Relay. BUT what the warning does not say is that it has to be fetched with the mutation in mind.
So basically you have to add the mutation you are going to execute on it in the future in the initial query like this:
fragment on Person {
firstname,
lastname,
language,
${UpdatePersonMutation.getFragment('person')}
}
This will add the necessary pieces to the entity in the store which are needed by the mutation.
In you case what you have to do is to add the FeatureLabelNameMutation getFragment to your AddCampaignFeatureLabelMutation query. This will bring back your featureLabel entity with the necessary information for the FeatureLabelNameMutation to succeed without warning.
The Relay documentation is very very poor on this and many other areas.
Relay expects any fragments for your mutation to come from your props. Since you're using data coming from your callback and not something from your container props Relay raises that warning.
Take a look at the source: https://github.com/facebook/relay/blob/master/src/mutation/RelayMutation.js#L289-L307
I have a custom entity definition like:
var Card = function () {};
var cardInitializer = function (card) {
// card.fields is defined in the metadata.
// card._cfields is an in-memory only field
// that breeze will not, and should not, track.
// Thus it is being added in the initializer
card._cfields = card.fields.slice();
};
When the data loads from the server everything is fine. The card.fields array has the corresponding data.
EDITED: Added more info and code of how manager is being set up
But when the data is round-tripped in local storage via .exportEntities and importEntities, the child data defined in the metadata, represented by the property card.fields in this example, is not loaded (the Array has length 0) during the initializer call, though it is subsequently available on the entity after load has completed.
Here is how the manager is being initialized:
var metadataStore = new breeze.MetadataStore();
metadataStore.importMetadata(options.metadata);
var queryOptions = new breeze.QueryOptions( {
fetchStrategy: breeze.FetchStrategy.FromLocalCache
});
var dataService = new breeze.DataService({
serviceName: "none",
hasServerMetadata: false
});
manager = new breeze.EntityManager({
dataService: dataService,
metadataStore: metadataStore,
queryOptions: queryOptions
});
entityExtensions.registerExtensions(manager, breeze);
var entities = localStorage[storage];
if(entities && entities !== 'null'){
manager.importEntities(entities);
}
Wow. You ask for free support from the harried developer of a free OSS product that you presumably value and then you shit on him because you think he was being flippant? And downgrade his answer.
Could you have responded more generously. Perhaps you might recognize that your question was a bit unclear. I guess that occurred to you because you edited your question such that I can see what you're driving at.
Two suggestions for next time. (1) Be nice. (2) Provide a running code sample that illustrates your issue.
I'll meet you half way. I wrote a plunker that I believe demonstrates your complaint.
It shows that the navigation properties may not be wired up when importEntities calls an initializer even though the related entities are in cache.
They do appear to be wired up during query result processing when the initializer is called.
I cannot explain why they are different in this respect. I will ask.
My personal preference is to be consistent and to have the entities wired up. But it may be that there are good reasons why we don't do that or why it is indeterminate even when processing query results. I'll try to get an answer as I said.
Meanwhile, you'll have to work around this ... which you can do by processing the values returned from the import:
var imported = em2.importEntities(exported);
FWIW, the documentation is silent on this question.
Look at the "Extending Entities" documentation topic again.
You will see that, by design, breeze does not know about any properties created in an initializer and therefore ignores such properties during serialization such as entity export. This is a feature not a limitation.
If you want breeze to "know" about an unmapped property you must define it in the entity constructor (Card)... even if you later populate it in the initialized function.
Again, best to look at the docs and at examples before setting out on your own.
consider the following code:
function getPersonById(personId, type) {
var p1 = new breeze.Predicate("Id", "==", personId);
var p2 = new breeze.Predicate("Type", "==", type);
var query = breeze.EntityQuery.from("Contacts").where(p1.and(p2))
if (!manager.metadataStore.hasMetadataFor(service.serviceName)) {
return manager.fetchMetadata().then(function () {
return manager.executeQuery(query.using(service));
});
} else {
var fromCache = manager.getEntityByKey('Contact', personId);
if (fromCache)
return Q.resolve(fromCache);
return manager.executeQuery(query.using(service));
}
}
Am I doing things the right way ? It seems to me that I have to write a lot of boiler-plate code just for fetching an entity. I had to make sure the metadata was known, and then if the entity is already in cache or not.
I'm facing an issue because if executeQuery is called, then the return value is an array. However if getEntityByKey is called, then the return value is an Entity. How can I deal with that in an elegant way ? Is there a way to force executeQuery to return a single Entity rather than an array ? (I'm expecting only one returned value anyway)
Your metadata test shouldn't be necessary for each query. If you add a fail method that handles any errors (such as no metadata) you can write that only once, but in reality if whatever service type JavaScript file you are using is loaded metadata should always be there. If you are moving datacalls to the view models then I would recommend rethinking that strategy.
the way you are doing your cache check is optional. Remember that there are two ways to query from cache - executeQueryLocally and setting the fetchStrategy. There are some instances where you will want to go refresh data from the server so I would definitely recommend trying to pull from cache first in each query and only going to the database on a needed basis. Generally I only have two methods for all my data retrieval, for each entity, although if you are tricky you can probably reduce that to sharing queries as well. Your queries are most efficient when you can reuse them for different orderBy's, where clauses, etc...
Last, if you want to return only a single entity just do it lklike you would any other array - catch the returned array results before sending them back and filter it down to something like data.results[0]. You could also query and then use a filter to find the first entity that meets sine criteria.
Trying to figure out how to extend entities that I query from breeze.js on a per-view basis in a single page application. Right now breeze is acting as the gate-keeper when it comes to extending (a.k.a materializing) them and I’m wondering what other options are available to allow me to do this. I initially started with knockout’s mapping plugin but found that it refused to handle child collections for some reason so I moved to using breeze’s constructor function and initializer methodology. The problem with this is that you can only define one custom "model" for an entity. I am looking for approaches that would allow a custom "model" of an entity on a per-view basis. I’ve already ruled out multiple managers. Querying meta-data multiple times is a huge unnecessary hit just to get this working.
This diagram visualizes what I’m trying to achieve. Both View 1 and View 2 ultimately query Entity B and both views require their own specific customization of the "model" of Entity B. Since View 1 loads first it’s custom "model" of Entity B "wins" and View 2 doesn’t have the opportunity to customize it. When View 2 eventually runs it’s query, any entities of type B that were already loaded by View 1 will have the custom "model" that View 1 defined which will make View 2 explode during binding. Any entities not already loaded by View 1 will now have View 2's custom "model" which would eventually crash View 1 if it could even get that far down the road. See this post.
My thought was to manually create my own custom "model" for each view that has an Entity observable and I could then iterate over every entity returned from a breeze query and new up this custom "model" and pass in the current item, assigning it to the Entity property. I don't really want to do this because I now have I'll have tons of iteration code everywhere and I'd much rather use knockout's mapping plugin. Pseudo code:
function view1EntityBModel(entity) {
var self = this;
self.Entity = ko.observable(entity);
self.myCustomProperty = ko.observable();
...
}
function view2EntityBModel(entity) {
var self = this;
self.Entity = ko.observable(entity);
self.isExpanded = ko.observable(false);
...
}
I was wondering if there are any other solutions available to achieve this same goal?
Or even better does anyone know how to make the knockout mapping plugin working on child collections?
I think the problem here is that by the time the mapping plugin gets a-hold of the breeze data the Children collection has already been converted into an observable array and the mapping plugin doesn't know that it needs to "call" the Children() property in order to get back a list.
var categoryMapper = {
create: function (options) {
return new categoryModel(options.data);
},
Children: { // this doesn't fire for the children
create: function (options) {
return new categoryModel(options.data);
}
}
}
function categoryModel(data) {
var self = this;
ko.mapping.fromJS(data, {}, self);
}
Guessing that you've moved on by now, but thought I'd offer a recommendation for others in a similar position.
Our solution to a similar situation borrows from the breeze.js TempHire sample solution which implements a client side repository/uow pattern. The solution uses an EntityMananagerProvider to manage multiple EntityManagers. The EntityMananagerProvider makes a single call for metadata, which is then used to create new child EntityManagers - satisfying your concern regarding multiple metadata calls. You can then use custom models/uow/repositories to extend the child manager for specific views.