I have the following database structure:
Children --> Gifts <-- Possible_gifts, where the arrow denotes 1-to-many relationship, i.e. "Each child can have many gifts and each one of those gifts is one of the Possible_gifts." (forming the classical many-to-many relationship). Possible_gifts table includes (among other things) the names of the gifts, the Gifts table only has the ID of the Possible_gift, the ID of the child and some other necessary data (like date, etc.)
Now in the Silverlight client I need to get not only the Child and Gift data from the domain service, but also the Possible_gifts table data (mainly the name of each Gift that is associated with the selected Child). I tried:
return this.ObjectContext.Children.Include("Gifts").Include("Gifts.Possible_gifts") as suggested somewhere else, but it doesn't work.
Does anybody have an idea how to solve this?
Thanks.
Discovered where the problem was. I was missing an [Include] attribute in the metadata class of the domain service. It turns out that having the above mentioned code in the domain service alone doesn't do the trick!
Related
Essentially I am creating an app that tracks packages - 1 tracking number to many - detailed updates for that tracking number.
For example:
Parent: Tracking #: 102391249
Tracking Updates:
Child1: Departed Location
Child2: At Local Fedex Facility
Child3: Delivered
The following is my current setup, the image on the left being the parent and right being the child:
Was this setup correctly? I am new to CoreData but coming from my knowledge of relational databases I am trying to make sure the id in the parent in the trackingid of the child to create the connection between the 2 "tables"
Set the one to many relationship between the Numbers and Details entities to connect the two entities. When you create an instance of the Details entity in your code, set its relationship to a Numbers entity.
child.numbers = parent
Where child is an instance of the Details entity and parent is an instance of the Numbers entity.
The numbers (changing the name to number would be clearer) relationship that you have in the Details entity gives you access to the tracking number. You can access the tracking number using the relationship and the Numbers entity's tracking number attribute.
let trackingNumber = child.numbers.trackingnumber
Since you have access to the tracking number from the relationship, you can remove the trackingid attribute from the Details entity.
By the way consider using clearer entity names than Numbers and Details. Your app deals with tracking shipping updates to packages. I recommend renaming Numbers to Package and Details to TrackingUpdates or ShippingDetails.
In the Module Builder, let's say I want to add custom modules Pets and Visits for my pet grooming salon.
If I want to be able to access Visits from a logic hook in the Pets module, and also Pets from Visits, and I also want to show each one as a panel in the other, should I:
Define a Many-to-One relationship from Visits (L) to Pets (R)?
Define a One-to-Many relationship from Pets (L) to Visits (R)?
Both?
I don't know if the answer's the same for Sugar; I think there might be a different "module builder" sort of thing for it.
As far as Sugar is concerned you'd want a many-to-many relationship if you want a panel in both modules.
However if you want to limit the relationship to a maximum of one Pet per Visit, then a one-to-many relationship is appropriate with Pet as primary module (L) and Visits as related Module (R).
Please note that in Visits the related Pet will possibly not be displayed as panel but as a relate field for such a relationship (at least in EditView, in Record View it probably is still displayed as Panel in SuiteCRM as it uses the old UI of Sugar).
Either way a relationship can always be accessed from both sides, so you don't need a second relationship)
Further info: https://support.sugarcrm.com/Knowledge_Base/Studio_and_Module_Builder/Understanding_Relationship_Creation_Options/
PS: If you want a one-to-many relationship but a panel even on the side where only one record of the other module can be linked to most at any time, then you can probably achieve this by creating a many-to-many relationship first and adjust the relationship's metadata to have true_relationship_type as one-to-many in code.
I've read through a bunch of tutorials to the best of my ability, but I'm still stumped on how to handle my current application. I just can't quite grasp it.
My application is simply a read-only directory that lists employees by their company, department, or sorted in alphabetical order.
I am pulling down JSON data in the form of:
Employee
Company name
Department name
First name
Last name
Job title
Phone number
Company
Company name
Department
Company name
Department name
As you can see, the information here is pretty redundant. I do not have control over the API and it will remain structured this way. I should also add that not every employee has a department, and not every company has departments.
I need to store this data, so that it persists. I have chosen Core Data to do this (which I'm assuming was the right move), but I do not know how to structure the model in this instance. I should add that I'm very new to databases.
This leads me to some questions:
Every example I've seen online uses relationships so that the information can be updated appropriately upon deletion of an object - this will not be the case here since this is read-only. Do I even need relationships for this case then? These 3 sets of objects are obviously related, so I am just assuming that I should structure it this way. If it is still advised to create relationships, then what do I gain out of creating those relationships in a read-only application? (For instance, does it make searching my data easier and cleaner? etc.)
The tutorials I've looked at don't seem to have all of this redundant data. As you can see, "company name" appears as a property in each set of objects. If it would be advised that I create relationships amongst my entities (which are Employee, Company, Department), can someone show me how this should look so that I may get an idea of what to do? (This is of course assuming that I should use relationships in my model.)
And I would imagine that this would be the set of rules:
Each company has many or no departments
Each department has 1 or many employees
Each employee has 1 company and 1 (or no) department
Please let me know if I'm on the right track here. If you need clarification, I will try my best.
Yes, use relationships. Make them bi-directional.
The redundant information in your feed doesn't matter, ignore it. If you received partial data it could be used to build the relationships, but you don't need to use it.
You say this data comes from an API, so it isn't read-only as far as the app is concerned. Worry more about how you're going to use the data in the app than how it comes from the server when designing your data model.
I worked with Entity Framework several years ago, and this may just be me being a bit rusty. I have detached entities, that in turn have multiple child entities. In my case it's a person entity and each person has multiple addresses.
myPerson.FirstName="update first name";
//assuming they already have an address in the first entry
//with appropriate primary keys and foreign key ids, I could do:
myPerson.Addresses.First().Line1="update line 1";
myPerson.Addresses.Add(new Address(){line1="weee",line2="aaaa" postal="12345", type="work"});
myDb.Person.Attach(myPerson);
myDb.Entry(myPerson).State=EntityState.Modified;
myDb.SaveChanges();
When I do a scenario like this, I get what I expect with first name. It updates the first name, and as expected actually blanks out all other fields (LastName, Birthday etc etc) in the above code. It doesn't however create the new address for the person, nor does it update the existing address.
I don't recall it requiring extra work for the database context to know how to update the related entities associated with the person above. In my google searches I seem to be hearing the story that I need to do a considerable amount of work loading collections from the db and then going to town that way. I hope that isn't the case.
The key part of the code you pasted are these lines...
myDb.Person.Attach(myPerson);
myDb.Entry(myPerson).State=EntityState.Modified;
The first line will attach the entire object graph to the context and set the state of each entity in this graph to Unchanged. The second line of code will set the state of just the root entity to Modified (the others, such as the Address entities, will remain in the Unchanged state). When the changes are saved, only the single entity will be updated.
Of course, this assumes that you are working with disconnected entities (using one context to fetch the object graph and another to perform the update). I assume you are as you are attaching the entity.
/* Rant On */
Disconnected entities is sadly something isn't handled very well in the EF space. You will find plenty of samples in books and blogs that attempt to address disconnected entities but these strategies quickly fall apart as you try to implement more advanced scenarios (such as object graphs including collections of related items).
/* Rant Off */
If models in Master Data Services are representations of subject areas (such as customer, product, etc.), is it possible to have a domain-based attribute that uses a different model as it's source?
For example, if creating a customer model and defining an entity called Customers, this entity will have address information for the customer. City, State/Province, Country, etc.
But rather than creating an entity for CustomerCountry, can I use a Geography model that contains a Country entity and link to that? Then I can also use the Geography.Country entity for Vendors and Employees.
No, you cannot cross model boundaries - the primary reason is that a model is the unit of versioning. There are two workarounds:
Duplicate the entities in question - i.e. copy the geography entities into your customer model
Reference an entity by code - i.e. add a CITY_CODE to your customer entity
Neither of these are great options 1) is unwieldy and 2) doesn't maintain automatic integrity.
Personally I use option 2) where I can with some additional logic/business rules outside of MDS to ensure that codes match. This is easier with codes that are global and do not change such as country and city codes.
This seems quite old but this is now possible in 2016 and is accomplished though Entity Synch. The idea is you can synch your entity across models. There are two ways to run the synch, either on demand or automatically.
See https://learn.microsoft.com/en-us/sql/master-data-services/entity-sync-relationship-master-data-services for more details