Let's say I have a model Parent that belongsToMany Children. I want to query some parent objects, and sort them so that instances of parent with the most children come first.
Likewise, is it possible to append other conditions to the children that are counted? For example, sorting parents by the number of female children under the age or 3.
What is an efficient way to accomplish this?
You can add child count pre-calculation field to the parent so u will never need to go to children object and this will make quaring very fast, also when you add a new child/delete child keep remember to increase or decrease the value in the parent.
same in the second question add tow field into parent male_child_count & female_child_count, life will be more easier :-)
Related
I'm building a workout app that has an entity called Workout and another one called Exercise.
A workout can contain multiple exercises (thus a one-to-many relationship). I want to show the users of my app the exercises contained in a workout but in an ordered way (it's not the same to start with strength exercises as with the cardio ones).
Apparently, when establishing this kind of relationship in Core Data, I need to use an NSSet, because if I try to use for example an Array where its elements are ordered, I get the following error:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Unacceptable type of value for to-many relationship: property = "consistsOf"; desired type = NSSet; given type = __NSArray0; value = (
).'
I have tried to check the "ordered" checkmark in my model, but then I get an error saying "Workout.consistsOf must not be ordered".
I have also tried to use an NSDictionary whose keys would be the position and the values would be the exercises themselves, but I'm getting the same error as above.
How can I show the users the exercises that a workout consists of in an ordered way?
Thanks a lot in advance!
P.S.: Here's a screenshot of the properties of my model.
Ordered relationships use NSOrderedSet, but CloudKit doesn't support ordered sets, so you can't use an ordered relationship and CloudKit in the same data model.
To keep an order, you need to have some property on Exercise that would indicate the order. This could be as simple as an integer property called something like index. You'd sort the result based on the index value. If there's something else that also indicates order-- like a date, maybe?-- use that instead of adding a new property.
I'm working on a module for a larger solution.
In this solution they tried in the past to work with DDD.
However that didn't turn out how it should of been because there was no DDD expert. (and there still isn't one present imo.)
Everything was under a single root aggregate, lazy loading was enabled, and so on.
Now for the new module we want to make it better.
However i'm failing to see how i can use DDD without lazy loading and not drain the entire database.
For example i have an object let's call it "B".
B has a flag let's say "AwesomeFlag"
B has children
If one of B's children is Awesome, then B is awesome as well.
If none of B's children is Awesome, then B isn't awesome.
Now if I would not work with DDD; I'd just get B and execute a linq query that check's if one of B's children is awesome without actually retrieving all of the children.
However if i got a domainobject where i am not allowed to perform queries, how can i do this?
Is DDD forcing me to get all of B's children just to get the calculated flag "IsAwesome" to work?
Or how am i supposed to do this correctly in a DDD environment?
A small hint in which direction i need to focus my research on would be appreciated.
UPDATE
As I was a bit broad in what my question is I'd like to rephrase whilst still using the same terms to be consistent.
B is awesome when one of it's children is awesome.
B itself, does not have a flag "awesome" as this is a calculated field based on the children.
B could have quite a few children, with the children each having allot of properties and data, which you do not want to retrieve just to check if one of the children is Awesome.
B has a method ShouldIBecomeADeveloper
If one of B's children is awesome, making B awesome, it should return a boolean "true"
If none of B's children are awesome, making B not awesome, it should return a boolean "false"
Disclaimer: although this is somehow a valid question, it is very broad, thus it may have many different valid answers.
You need to analyze the business requirements regarding the valid states in which the system is allowed to be. For this you need to answer the question: after a child of B becomes awesome, how fast needs B to become awesome as well?
There are two answers:
Immediately, in a strongly consistent matter. This means that the "awesome mutation" of a child of B and the "awesome mutation" of B are performed in an atomic fashion, they are in the same transaction. In this case you must load B and all its children before mutating one of its children awesomeness. The children of B are nested entities inside the B Aggregate.
It can be delayed, eventually changing its awesomeness to match the business rule, that is, the system can be for some time in a temporary invalid state. In this case, the children of B are also Aggregates. You need a way of mutating B when one of its "past childrens" mutate and for this you can use a Saga/Process manager.
In neither of the two cases you don't use lazy-loading, there is not such thing in case of DDD Aggregates. You can't anyway, if you have pure Aggregates, with no dependencies to Repositories (as you should).
B itself, does not have a flag "awesome" as this is a calculated field based on the children.
Even though "awesome" is a calculated field any operation you perform on the child entity has to go through "B" only, as it is the aggregate root. So you could have a state in "B" called numberOfAwesomeChildren and a child can become awesome/not awesome only when some operation happens on it and since all the operations are directed via "B" only, you can update the numberOfAwesomeChildren whenever a child becomes awesome/not awesome.
So "B" is awesome when numberOfAwesomeChildren is greater than zero.
Even this solution won't solve your lazy loading problem, since to perform an operation on a child entity you will end up loading all the child entity. You may have to have a re-look at your design.
i need some help for my problem related to complex datatype in C#. I have following type of data and i want to save it in variable, but it will be performance efficient as i have to use it for search and there will be lot of data in it. Data sample is as follow:
ParentNode1
ChildNode1
ChildNode2
ChildNode3
ParentNode2
ParentNode3
ParentNode4
ChildNode1
ChildNode2
Node1
Node2
Node3
Nth level Node1
ChildNode3
ParentNode5
Above data is just a sample to show hierarchy of data. I'm not sure nested List, Dictionary, ienumerable or link list which will be best related to performance. Thanks
If you know that a search will take place at a single level, then you might want a list of lists: one list for each level. If your hierarchy has N levels, then you have N lists. Each one contains nodes that are:
ListNode
Data // string
ParentIndex // index of parent in the previous list
So to search level 4, you go to the list for that level and do your contains or regex test on each node in that level. If it matches, then the ParentIndex value will get you the parent, and its ParentIndex will get you the grandparent, etc.
This way, you don't have to worry about navigating the hierarchy except when you find a match, and you don't have to write nested or recursive algorithms to traverse the tree.
You could maintain your hierarchy, as well, with each top-level node containing a list of child nodes, and build this secondary list only for searching.
the job of the layout is to place vertexes at given locations. if the layout is iterative, then the layout's job is to iterate through an algo, moving the vertexes with each step, until the final layout configuration is achieved.
I have a multi-level graph - say 100 objects of type A; each A object has 10 objects as children; call the children type B objects.
I would like the layout location placement algos to operate on objects of type A only (let's say) - and ignore the B objects.
The cleanest way to achieve this objective might be to define a transform to expose those elements that should participate in the 'algo' placement operation via the step method.
Currently, the step methods, assuming they respect the lock flag at all, do their calculations including the locked vertexes first - so lock/unlock won't work in this case.
Is it possible to do this somehow without resorting to multiple graph objects?
If you want to ignore the B objects entirely, then the simplest option is to create a graph consisting only of the A objects, lay it out, and use the locations from that layout.
That said, it's not clear how you intend to assign locations to the B objects. And if the A objects aren't connected to each other at all, then this approach won't make much sense. (OTOH, if they aren't connected to each other then you're really just laying out a bunch of trees.)
Is there a way to formulate a Core Data predicate for a given object, representing the head of a singly linked list, and all of the other objects in that list?
E.g., I have objects, each of which has a relationship to another object (say nextObject) and I want a predicate for a specified object and all other objects reachable by traversing nextObject (until it is nil).
CLARIFICATION:
I'm using these for a UITableView's NSFetchedResultsController, so these need to be part of the fetch, not something I iterate through in code.
You wouldn't use a predicate for a linked list. Instead, you would just start with the first object of interest and walk the relationships by calling nextObject until you hit one that did not have a nextObject value.
You can find the first and last objects with a predicate in a fetch just by looking for previousObject==nil and nextObject==nil.
Predicates do not understand arbitrarily long relationship chains. They understand a chain like enity1.entity2.entity3 but not nextObject.nextObject.nextObject... because they have no way of knowing when to stop.