I have created a few Lightswitch HTML apps. Each app has an ApplicationData data source;however, in addition they relate to each other via one or more OData data sources.
For example:
A HumanResource app contains
Employees table in it's ApplicationData.
A Project Management App contains:
a Tasks table and a Projects table in it's ApplicationData datasource
a Employees table in a related OData datasource (HumanResourcesData) which loads data from the Employees table in the HumanResouce app's ApplicationData datasource.
A Task has an Employee related to it as 1..0 or 1
The problem is
myapp.activeDataWorkspace.ApplicationData.Tasks.expand("Project, Employees").execute());
DOES NOT WORK which is very understandable.
Tasks can be loaded because they reside in "ApplicationData", Employees cannot because it resides in "HumanResourceData". OData cannot fetch data from 2 sources and magically relate them, and neither can Lightswitch apparently, at least when your manually loading data.
Two solution I can think of are:
use task.getEmployees().then(function(results){});
This will cause a roundtrip to the server for every task. NOT GOOD ENOUGH
myapp.activeDataWorkspace.ApplicationData.Tasks.load()
myapp.activeDataWorkspace.HumanResourceData.Employees.load()
//The mystery method that I'm looking for
Resolve_My_Datas_Relationships_Please_Lightswitch();
While reviewing trace.axd I noticed that when I drag and drop the collection into the viewmodel and have all the data loaded automagically with related entities and all, I get one call to the HumanResourcesData datasource for each related entity, which looks exactly like solution #1.
This leads me to believe that solution #2 does not exist since it is not the approach that the LightSwitch Team has taken, for which they may have valid reasons (probably because it's very hard to optimize for any particular set of queries if you do not know what they are before hand)
Can anyone shed some light?
Related
I'm building an app that gets a lot of data from a web service. The app consists of different entries that have relationships to each other. Let's make an example and say I'm building a TV show tracking app, all the data is coming from the web service, but I want to mark episodes as watched, which is a custom property on one entry so far. All of this gets save in Core Data. I have these entries:
Show ⇒ has many seasons and episodes
Season ⇒ has many episodes and one show
Episode ⇒ has one show and one season
The main part I'm currently struggling with is how I can best update all of these entries when the web service has an updated version of the data (maybe the show got a new season or some wrong data got fixed). At this point, the only custom property on these entries which differs from the data the web service provides is the watched attribute I created on the Episode entry.
So far I tried different ways, like removing the old data and just adding the new one (the custom watched attribute is a problem here) and I also looked into merge policies like NSMergeByPropertyObjectTrumpMergePolicy but this doesn't play nice with relationships and I got to a roadblock there.
Is there a better way or best practice how to solve this?
I am new to Dynamics FnO, and recently followed the articles to access data through oData, and was successful.
What I see missing in the data objects that I normally receive in integrations out of the Microsoft World is the created/updated timestamps.
I am trying to put a synchronous data flow from FnO to my NodeJs application, so that my app keeps polling data from FnO whenever there is a change. This can be achieved easily if there were timestamps with the data that flows in.
Is there a way to setup those timestamps somewhere?
You have to make sure that the underlying table that you are querying has the fields added on it, and also that the data entity you are accessing through odata has the fields setup up on it as well.
Make sure this is setup on the table:
And then you have to drag and drop the field(s) from the datasource field list to the exposed field list in the data entity:
After this, you will have these fields
I'm new in iOS, Swift. My application has one entity named "Category" in a relationship to many entities named "Movies".
"Movies" entities are changing, according to data that I get from a url. I'm looking for a way not to have duplicated movies records in each category, and I can't think of an easy way to do it.
Core-data does not have a built in way to ensure uniqueness. You have to manage that yourself. But it is not that hard. Before every insert/update do a fetch - if it does not exist then create it, it if already exists then update it. If you are updating many at a time (for example from a network request that has updates for many entities) then fetch all of then in a single fetch request and then create or update as needed.
Generally these fetches are done using uniqueIds for each entity. If you don't have any uniqueId for you entities then you have a deeper problem than core data. You could have two movies with the same name, or one movie that has different names. If you don't have anything that says the same, then you fundamentally don't have any way to know if you need to make another entity or update an existing one. It is possible that you can use the movie name, but I would not recommend that. I suggest that you look closer at your server api and see if there is a uniqueId that is served, and if there is none then you have to have it fixed by the server team.
app scenario: on the UI, a button is tapped to get contact list from the server. the request goes to subproject which does the download and parsing and returns the result thru its delegate to the UI. so far everything works properly. lets say there is no internet connection and we cant have the contact list. to solve the problem, I want to cache the data in core data. if there is no internet, the cached data will be returned. now the question that bugs me, is it possible to create one data model and use it in subproject to save the data and in UI where data get pulled and edit from the same data model?
so basically i want to access core data from different subprojects and UI.
i couldnt find hints or tutorials regarding this issue. any ideas?
thanks in advance!
edit:
a project "b" that is added to the parent project "a". the project "b" is actually a static library.
if i let the library to do the saving and returning data to UI, wont it be inefficient to get all data from core data then send it to the UI?
i actually hope that there is a way to use same data model in both UI and the library.
i want prevent the UI to have huge load of data. its better to hace core data to handle that incl. memory mangement. i'm still reading some sources and trying to implement it on a test project.
I would argue that only the main project should deal with persistency, as than you can always decide to handle it differently — save it permanently or not, use core data or a home grown sql wrapper…. So it would be up the the delegate to decide what to do with more data.
But along with the delegate protocol you could decide to maintain different model protocols that define, what your models can hold. this would be independent to the implementation. The delegate now could return objects — no matter if core data models or not — to the delegator if this objects conforms to the protocols. The delegator in the sub module now could check for values on the server and/or in the cache.
I'm building a web app for bookmark storage with a directory system.
I've already got these collections set up:
Path(s)
---> Directories (embedded documents)
---> Links (embedded documents)
User(s)
So performance wise, should I:
- add the user id to the created path
- embed the whole Paths collection into the specific user
I want to pick option 2, but yeah, I dunno...
EDIT:
I was also thinking about making the whole interface ajaxified. So, that means I'll load the directories and links from a specific path (from the logged in user) through ajax. That way, it's faster and I don't have to touch the user collection. Maybe that changes things?
Like I've said in the comments, 1 huge collection in the whole database seems kinda strange. Right?
Well the main purpose of the mongoDB is to support redundant data.I will recommend second option is better because In your scenario what I feel that if you embed path collection into the specific user then by using only single query you can get all data about user as well as related to path collection as well.
And if you follow first option then you have to fire two separates queries to get all data which will increase your work somewhat.
As mongodb brings data into the RAM so after getting data from one collection you can store it into cursor and from that cursor data you can fetch data from another collection. So if we see performance wise I dont think it will affect a lot.
RE: the edit. If you are going to store everything in a single doc and use embedded docs, then when you make your queries make sure you just select the data you need, otherwise you will load the whole doc including the embedded docs.