I want to create a custom entity linked to the contact entity.
The purpose of this new entity is to store competitors of a contact (it is not like the default MCRM competitor entity that as for purpose to store your own competitors).
I tried many ways to do that by creating an entity with single names of competitors & an entity linked to contacts to store competitors names but after, you get the "add a new competitor" & "add an existing competitor" that are refering to the second entity I created: you see the whole list of competitors including duplicates (if many contacts have the same competitor, you see many times the same competitor name).
Is it a relationship problem, or should I use an other way?
Thanks
Did you create a 1 -> Many relationship? E.g. When two contacts share the same competitor you create 2 competitor records.
Try using a Many -> Many relationship, that way two contacts can share the competitor record, e.g. you have 1 competitor record for 2 contact records.
This should reduce duplication.
Related
I'm currently building up an app for grocery-shopping where I'd want to share a set of data (shops, products, recipes and tags) within the family.
Let's say I have Entities called Shop, Product, Recipe and Tag. How can I establish an relation in CloudKit, that allows each invited user to edit shops, add products or read recipes?
I want to share all known information inside something kind of a "family store" but it seems like there's no documentation on how to do this using CloudKit and CoreData, so I hope for someone who already build sharing of a set of entities between multiple users.
I suggest setting up a Family entity in CloudKit, alongside your Shop, Product, Recipe, and Tag entities. The Family would be the parent entity, and the others would have a CKReference property that points to a Family record.
In order to coordinate sharing records between users, you could look at CKShare which is the mechanism Apple provides for sharing records from the private database (documentation).
In your case, you would share Family records between users. As long as the other records are set to have the Family record as its parent, they will automatically be shared along with the Family record's CKShare.
There is a tutorial that I like on Medium that walks through how it works which should apply pretty well to what you are trying to do: https://medium.com/#adammillers/cksharing-step-by-step-33800c8950d2
The whole workflow is more than you can shove into a Stack Overflow answer. I hope this helps get you started.
For the n:m list membership, Microsoft CRM uses an intersect table called ListMember. With a solution/plugin I need to attach new columns to this table. I know that I could create a new entity with this and keep it in sync with ListMember, i.e. creating one whenever a member is added to a list and modifying it when a member is moved to a different list, etc. But that's quite a lot of overhead I think.
Is there a way to attach new fields to to the ListMember entity in CRM 2011?
Source: How to integrate with Dynamics CRM Marketing Lists with a plug-in
If you need to have additional fields for a many-to-many relationship you must create a manual relationship (by creating an intermediate entity.) This is not an oversight, it is in the Dynamics CRM training material.
As for Marketing Lists, you shouldn't be trying to add more information to this relationship - it is a flaw in the solution design/architecture.
You wouldn't need to keep anything in sync. Use Dynamic Marketing Lists and they will be kept in sync. The only purpose of a Marketing List is to create the activities for a Campaign/Quick Campaign. If Marketing List membership is being used for another purpose that is a solution design issue that needs to be resolved.
I have read many about how to configure many to many realtionships with EF Code First and fluent configuration. But I couldn't understand why I should create an extra entity for the junction table. Lets assume that I have the following entities:
Department
----------
Id
Name
Material
----------
Id
Name
Now I want to keep records of materials for each department. So I need
DepartmentMaterial
-------------------
DepartmentId
MaterialId
Quantity
What I have read so far I need 3 entities: Department, Material and DepartmentMaterial. So actually I am mapping each table to a corresponding entity which was not I intended to do when I started to learn about DDD. I assumed that EF is going to map that junction table automatically and also queries about material quantities can be done over Department.
Hence, is it possible in EF Code First to configure fluently such a relation without an extra entity?
The junction table can stay out of the conceptual model (class model) if it's only got two foreign keys (DepartmentId, MaterialId). You want to record some data about the association. That's OK, the quantity belongs there. A department has quantity x of material y. Saying that a department has a quantity is meaningless.
This is not against DDD principles. The association class is a first-class citizen in the class model. It could even have its own behavior (like limiting quantities for certain department/material combinations).
This means that your model will not contain a many-to-many association but Department 1-n DepartmentMaterial n-1 Material. And you'll have to query materials of departments through the junction table. This is a very common situation. I hardly ever see pure junction tables in real life. They're collector's items.
Example query:
var query = from d in db.Departments
from dm in d.DepartmentMaterials
select new { Department = d, Materials = dm.Select(x => x.Material)};
I have the following:
Deal, Contact and DealContact. A Deal can have many Contacts. A Contact can belong to many Deals. DealContact is used to maintain both of this using two relationships: to-one called deal and a to-many called contacts. I also need to store a primary contact separately in DealContact. This is another to-one relationship called primary.
Contact then has an inverse to-many to DealContact called dealcontacts and a to-one called primarydealcontact. A Deal does not have an inverse to DealContact. A deal also does not have a direct relationship to Contact.
In SQL I would've modeled this using a join table. I'm trying to carry this over using DealContact as I need additional properties stored besides just the Deal and associated Contacts.
Any suggestions on if this setup is correct or perhaps an easier setup would be very helpful.
Let me put things down with a small old school ASCII model.
Deal
- stuff
Contact
- stuff
- dealcontacts ->> DealContact
- primarydealcontact -> DealContact
DealContact
- stuff
- deal -> Deal
- contacts ->> Contact
- primary -> Contact
All right.
This stuff is not very coredataish.
First thing first.
Deal: I do not see the point not to have an inverse relationship to DealContact.deal. You'll have to handle the Deal deletions manually to ensure there is no DealContact left without a related Deal. That inverse relationship costs you almost nothing.
Contact: why is Contact.primarydealcontract a to-one relationship? You sure a Contact can't be the primary contact of several Deal?
Details all that anyway. Let's discuss what is not very coredataish. DealContact.
What's the point of that entity? Basically, you have Deal connected to many Contact, including a primary Contact. The additional fields in DealContact are most certainly related either to the Deal or a Contact, so why a dedicated entity for them?
This is how I see the entities:
Deal
- stuff // from Deal & from DealContact
- contacts ->> Contact
- primarycontact -> Contract
Contact
- stuff
- deals ->> Deal.contacts
- dealsprimary ->> Deal.primarycontact
Core Data will create the necessary relationship tables to keep track of the many-to-many relationships. Core Data does that very well.
Of course I do not know all the details of your application, so my suggestion is, well, a suggestion. Nothing more. It may suits your needs, or not. But considering what you told, it should work for you.
So it turns out that after redesigning my Core Data model and removing the DealContact entity I found that I was actually not passing along the DealContact object (which had the core data accessors) to removeContactsObject from the set. After clearing this issue (which was greatly simplified by removing DealContact entity from the model all together) [deal removeContactsObject:oneContact] worked exactly as expected.
I've got a data model where there is a Person entity, which has a transformable attribute which is an array of dictionaries containing information. The model is much bigger than that, this is just the part I'm having trouble with. It was designed this way by an old developer, and in taking over the project I need to migrate this to be 100% core data.
So what I need to do is create a new entity, then step through each dictionary in the Person's array and create new instances of that entity with the information from that dictionary. I thought I could use an NSEntityMigrationPolicy to set up a custom migration for this new Entity, but it seems the Core Data migration is expecting X number of source entities to translate to X number of destination entities. Because I technically have 0 source entities right now (because they're in an array that Core Data doesn't really know anything about), I'm not sure how I can make the migration create new entities during the process.
What, or rather where in the migration procedure, is the best way to do what I'm trying to accomplish? I've always used lightweight migration in the past, so this is my first adventure in custom migration.
It would help to have a sense of your data model (schema) - but let's assume that your Person entity now holds home address and list of favorite restaurants. And let's further assume that you will be creating new entities Address and Restaurant along with the following relationships:
Person has one Address, so there's a to-one relationship from Person to Address called "homeAddress". There's an inverse to-many relationship from Address to Person, because many people could live at the same address.
Person has a to-many relationship (called restaurants) to Restaurants. Restaurant could also has a to-many relationship to Person (though this might be one of those cases where bidirectionality doesn't really make sense).
Anyway, the point is that now - in addition to your PersonToPerson NSEntityMigrationPolicy subclass, you will also have PersonToAddress and PersonToRestaurant. These will be the places that you unpack the old data and use it to instantiate and initialize new Address and Restaurant objects.
Of course, there are lots of other complicating issues. For example, you won't want to be creating a new instance of the same Restaurant for every Person who likes it. You will need to keep track of newly created Restaurants.
You will want to order your mappings strategically - probably with PersonToPerson first.
You might want to look at Marcus Zarra's Core Data sample code and maybe even buy his book.