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.
Related
I'm trying to get my head around NoSQL and Google Cloud Datastore, and I don't know how to chose between two different options for storing data.
I have a list of orders, and every order is for an unspecified number of products. What are the pros/cons of storing the product list as an array property for the order entity vs having product child entities for each order parent?
Firstly, be well aware of the distinction between the 2 possible approaches of implementing a relationship between entities:
one entity can contain a Key type property pointing to another entity (which might or might not exist!) - this is a functional relationship only, not one at the datastore level
having the 2 datastore entities in a parent-child (ancestry) relationship, inside the same datastore entity group.
Using the 2nd one has scalability implications, see also:
Ancestor relation in datastore
E-commerce Product Categories in Google App Engine (Python)
As for storing a list as an array property vs as separate entities, see Creating your own activity logging in GAE/P (where repeated properties is just how array properties are called in the ndb client library context).
So, I have a core data database with multiple relationship already populated with data. My problem is that I created the relationships between the tables but i don't know how to set them in code. I only need to set one and then I can figure it out for the rest of them.
For example: Colleges has the "has Groups" relationship because one college has many groups. The Groupe table has the "bellongsToColegiu" relationship becouse one or more groups are in one college.
I know that, i have to set the ".bellongsToCollegiu = Colegiu?" or ".hasGrupe = Grupe?" but i don't know how to fetch the college in proper way.
For now I have only one college in database.
Can someone help me with this please? I've been knocking my head for a few days and got nothing.
Thank you and have a nice day!
When you create entities and relationship between them Xcode also generates code for handling those relationships. The name pattern for code that handles relationships are
The same as the name of the relation for to-one relationships
addToX and removeFromX (x is the relationship) for to-many relationship.
So you should have for instance addToHasGrupe(_ value: Grupe) on College and that you can add a group instance to and Grupe should have a belongsToColegiu property that you can set to a college instance. Autocompletion should help you.
You can fetch a existing 'Colegiu' from the data base or create a new one. for both fetching and creating new one you would need a managed object context. Managed object context is the last part of the data stack which has 3 components comprising of 1. Persistence store, 2. persistence store coordinator, and 3. managed object context.
Here is how to create a stack:
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/InitializingtheCoreDataStack.html
Then you can create a new object:
let newItem = NSEntityDescription.insertNewObject(forEntityName: 'Colegiu',
into: 'reference to managed object context here')
or you can search the existing one by calling fetch on managed object context,
Keep in mind CoreData is a complicated topic and it takes time to put the head around. All the best.
My question relates to overall design within entity framework 6. My model has an entity type called Person. Each person consists of multiple values, some of which it is important that i track the previous values of these properties. An example of that includes Last Interaction Date and Status
The model currently has a separate entity for each property i wish to track historical status on in this case Person_Status and Person_lastInteraction; the relationship is created with a 1 to many relation.
I extend the Person partial class to allow methods for updating the these tracked properties.
....There has to be a better way!
My Concerns:
Every time i want to track a different property i have to create a new entity just for tracking those particular property changes, requiring DB changes
Because EF still exposes the property its possible someone could change the person status without using the methods added to the class.
I'm re-writing a lot of the same exact code to do essentially the same thing
Has anyone encountered a situation as such, what did you do?
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