I have two subgrids
Parent
Children
Now I will be adding entries to it from the contact entity
What I want to achieve is, I want to create parent-child relationship among the data that are there in these two subgrids so that I can use it for querying in future
Usage scenario:
I have a entity form for a entity called as MedicalCase
MedicalCase form will have two subgrids for "Children" and "Parent"
Now I will be able to add children and parent records to subgrid from the Contact entity
For these records in the parent and children subgrid, I want to specify, which parent is the father/mother of which child
I don't have the luxury of editing the Contact records, is there any other means that you can think of?
Someway in which I can record the relationship between child and parent in the subgrids
Hope I am clear enough, feel free to ask me if you need any clarifications
I'm having a hard time understanding the situation exactly, but after several re-reads it sounds like you need a custom many-to-many relationship entity. Create an entity called ChildParentRelationship (CPR) which should have a lookup to Child and a lookup to Parent. Your Medical Case form should have a sub-grid for CPR entity. When a user creates a new CPR record, they will specify the Child and Parent. Does that get you what you need?
Related
I've stumbled upon a problem: "I can't split my domain models into aggregate roots".
I'm a junior developer and novice at DDD. I really want to understand it, but sometimes it's really confusing.
From this point I want to describe my domain briefly.
My poject dedicates to provide users opportunity to create any kind of documents by themselve. Users can create a new type of document. Each new type consists of its attributes. Then a user of this application can create a concrete document based on its type. User can also send the document for approval. An approval flow is different for each types.
So, we have the following models:
DocumentType/ DocumentTemplate - acts as a template based on which
concrete documents are created. It has one to many relationship with
Document.
DocumentsAttribute - represents an attribute of document.
It has many to many relationship with DocumentType.
AttributeValue - when a concrete document is created, It looks at
its type and creates values for attributes, which has
its type. Many to many relationship with Document and Attribute.
Document - represents a concrete document that is created by users.
There are others models but I don't think that they make sense.
As you understand, here I apply Entity Attribute Value (EAV) pattern of data model. You can see a diagram that shows relationships in the database.
And my problems are:
I have a lot of entities in my model besides I have described.
I think that Document is definitely an aggregate root in my Domain. Because such things as ApprovalProcess which is aggregate cannot live out of it.
Here is the first question:
ApprovalProcess consists of its steps. Each step is an entity since it is mutable. A step has its state that can be changed. ApprvalProcess's state depends on its steps. Here we have a business invariant: "ApprovalProcess can be approved only if all its steps is approved".
I think that it is an aggregate root because it has the business invariant and contains entities that cannot live out of it. And we don't want to allow to have direct access to its steps in order to keep ApprovalProcess consistent.
Am I mistaken that ApprovalProcess is an aggregate root? May it is just an aggregate?
Can one aggregate root exist within another one as it's part? Does it mean that ApprovalProcess is just aggregate because Document is responsible for access to its parts? But when ApprovalProcess's step is approved, Document delegates an operation to ApprovalProcess.
For example:
Document doc = new Document(...);
doc.SendForAooroval(); //ApprovalProcess is created.
doc.ApproveStep(int stepId); // Inside the method Document delegates responsibility for approvement to ApprovalProcess.
Or I should leave Document and ApprovalProcess separately. Hence Document is going to refer to ApprovalProcess by Identity. And we have the following scenario:
Document doc = documentRepository.Get(docId);
doc.SendForAooroval();// A domain event "DocumentCreatedEvent" is raised.
DocumentCreatedEventHandler:
ApprovalProcess approvalProcess = new ApprovalProcess(event.DocId); // ApprovalProcessCreatedEvent is raised
approvalProcessRepository.Add(approvalProcess);
approvalProcessRepositroy.UnitOfWork.Save(); //commit
But if ApprovalProcess's state changes, Document's state also changes. ApprovalProcess is approved then Document is also approved. Another word ApprovalProcess is kind of part of Document's state. Only thanks to it we can know that Document is approved.
And the biggest problem that I'm experiencing:
DocumentType is also an aggregate root. It consists of its attributes and ApprovalScheme. I haven't mentioned ApprovalScheme yet on purpose to keep my explanation as simple as possible. ApporvalScheme consists also from some entities. It's just an approval flow for DocumentType. ApprovalProcess is created according to ApprovalScheme of DocumentType which has Document. ApprovalScheme cannot exist without DocumentType. One to one relationship.
Document refers by identity to its DocumentType. Is it correctly?
At the begining of this task I thought that DocumentType should be a part of Document.
DocumentType has many Documents but in my domain It doesn't make sense. It doesn't represent the state of DocumentType. DocumentType can be marked as deleted but can't be deleted.
Document and DocumentType are two different aggregate roots. Am I right?
Thank you so much If you read it. Thank you a lot for you attention and help!
Sorry for my terrible English.
Am I mistaken that ApprovalProcess is an aggregate root? May it is
just an aggregate? Can one aggregate root exist within another one as
it's part?
These questions doesnt make any sense to me. An aggregate is a group of entities and value objects, where one of the entities is the parent of the group. The aggregate root is the parent entity of an aggregate. A particular case is when the aggregate is just an entity. The entity alone is an aggregate and the entity is the aggregate root of course.
I think that I would try to model your problem from another point of view: as a state machine.
I see ApprovalProcess as a flow a document follows, not as an entity. I don't know the flow diagram of the process, but I guess that what you call "steps" would be the "states" a document can have during the process, and you have transitions between steps, so that first when you create a new document, it is at a starting step, and through the lifetime of the document, it pass from a step to another, till it reaches a final step (e.g. document approved).
So the document entity would have behaviour that changes its a state.
For example, in Java you can implement the state pattern (a state machine) with enums.
I have a question about the Core Data Model and the Cascade Delete Rule.
My Core Data Model is this one:
As you can see the User Entity has a "To Many" Relationship with the Orders Entity.
Also the Orders Entity has a parent entity called Cuisines, as each Order needs to be from a list of available Cuisines.
The User To Orders Relationship delete Rule is Cascade (the inverse is nullify) as I want all orders to be deleted if the user object is deleted.
My question is what happens with the Cuisines Entity if I delete the User?
The Cuisines should be available for all orders placed for other Users as well, so it must persist. Will it be also deleted?
If yes, how should I create my model and set the delete rules to avoid this?
Specifying Cuisines as the parent entity for Orders means that each Orders object is a Cuisine - albeit a specific "type" of Cuisine. Each Order has three attributes: numOfOrders, rating and name. When you delete an Order (albeit through a cascade rule), you are deleting one object with all three attributes - there isn't a separate Cuisines object to be deleted.
But you want each order to be from a list of available cuisines. So replace the parent/subentity link between Orders and Cuisines with a relationship. Each Cuisine can be related to several different Orders, so the relationship would be to-many. Conversely, each Order relates to only one Cuisine, so the inverse relationship will be to-one. When you delete an Order, you want the related Cuisines to remain (for use in other Orders) so the delete rule would be "nullify".
We currently have some parent child relationships between Orchard content items built using the Container/Containable structure.
The parent item is a manufacturer, the child item is a range, the child of a range is a product. We have this kind of parent child relationship 4 levels deep.
This is all working but on a page where we have a list of products from different manufacturers and want to display some information about the manufacturer with each product performance is terrible due to select n+1 issues.
This is because we are bringing in all the products in a single query, but then for each product a query is executed for the common part to find the container ID and then a separate query is executed for each manufacturer content item.
I've added query hints to get the common part eagerly, but we still have the select n+1 issue to get the actual parent content item, obviously at lower levels in the hierarchy this problem is magnified.
I think this is because of the lazy field for the Container on the CommonPart - I can't see a way of avoiding this with that structure, or telling the content manager to fetch it eagerly.
I then looked at defining the structure ourselves using http://docs.orchardproject.net/Documentation/Creating-1-n-and-n-n-relations#BuildingaRelationBetweenContentItems but the example there for relationships between content types again uses lazy fields to load in the parent.
What I want is to execute a single query to get me every product with its parent range and its parent manufacturer, but I can't see how to do this. Are there any examples of this?
I apologize if this question exists already on the site posted a different way but after browsing I couldn't find anything.
I have an entity in core data called category which stores categories and subcategory objects. I would like to have create a relationship between categories and sub-categories. In my app, I have the following requirements:
sub-categories can belong to multiple categories.
Categories can have multiple sub-categories
A category will hold a list of its parents and children.
So really, sub-categories are just categories.
What I would like is to find a way to create my category entity to have that parent child relationship as well as a list of parents and a list of children for each category.
Can someone suggest an approach for this problem? would I need a "junction" entity? What would a fetch request look like to get a category object from the entity and populate its parents and children lists while taking advantage of the whole object graph concept (if possible)
Thank you.
Simply create the Category entity and add two relationships to itself: subCategories and parentCategories, which are of course each others reverse relationships. Now you can access the corresponding lists very simply:
NSSet *children = category.subCategories;
NSSet *parents = category.parentCategories;
I have an entity User entity which is a parent entity to a Friend entity.
The User entity has a to-many relationship with an entity named Article.
The idea is there are users saved and also friends (from Facebook), the to-many relationship to Article is set on the User entity as this is being subclassed by Friend.
My question is how can I request all Articles by Friends and not by all users ?
I am having trouble setting an Predict to omit User entities and keep only Friend entities.
Thanks.
Is there a reason you are building a parent/child entity design here? Parent/Child entities come with a really heavy cost if you are persisting to a sqlite store. It is almost always a better idea to just have a single entity and have a flag stating if it is a friend.
Also, I know of no way, at the database level, to filter out the parent from the child in this design. It can be done in memory after the fetch by requesting the entity.name but that will not turn into a sql call properly.