Trying to create a TFS query which displays a list of children PBIs of a Feature without displaying the feature. The Feature and PBIs are linked through child-parent relationship.
Any idea if this is possible?
Josh
No, we cannot only display the children workitems with flat for the Parent/Child linked work items.
We can only query both Parent and Child workitems with the query type Work items and direct links or Tree of work items.
However you can create a Work items and direct links or Tree of work items query with both Parent and Child workitems, then open the query in Excel then filter out the Child workitems. Or trying list the children workitems with TFS API.
Reference this similar thread : Get child work items for a specific parent in TFS
Related
I have a database which will store a number of users and the items belonging to those users. users and items will be stored as nodes. My initial approach was to have a user node with properties of username, email, and item with properties name and category, with their inbetween relatiohsip being:
(item)-[BELONGS_TO]->(user)
After reading an article in the neo4j blog, I moved the category property into a separate node, as it may belong to multiple items.
What I am concerned about is that now in a scenario of thousands of items, category nodes would have thousands of relationships. How would that affect the overall performance if I were to search for a single item and the categories it belongs to?
Dense nodes are indeed an issue (and there's quite a few approaches to increase the performance / solve the issue). Having said that, the denseness here is on the side of the category (1 category having thousands of relationships with items). If your entry point into the graph is the item however ... getting all the categories it belongs to (just a few I imagine) should not cause any problems whatsoever.
Hope this helps,
Tom
You can avoid having to create Category nodes and the relationships to them by indexing the category property of Item nodes. This would allow you to quickly find all the Items that belong to a single category.
I'm struggling with creating a suitable Core Data model for my app. I'm hoping someone here can provide some guidance.
I have two entities -- "Goals" and "Items". The Goals entity contains only a goal description, but any goal may have any number of subgoals, and these may extend multiple levels in a tree structure. Subgoals are to be contained within the same entity, so presumably the Goal entity will contain a pointer to "parent" which will be the parent goal of any subgoal.
There will also be an "Items" entity that contains a couple of text fields and a couple of binary items, and must be linked (ideally, by a unique identifier, perhaps objectID) to the particular goal or subgoal the item(s) are related to.
I am totally fumbling with how to set this model up. I know what attributes need to be in each entity, but the relationships, particularly between goals and "subgoals", has me stumped. I don't seem to be able to turn up any good examples of tree structures in Core Data on the Internet, and even the couple of books I have on Core Data don't seem to address it.
Can anyone here help an old SQL programmer get headed the right direction with these relationships in Core Data? Thanks.
Have you tried creating a one-to-many from Goal to itself, and a one-to-one from Goal to Item? The only thing I would worry about here is circular references.
Also, read Relationships and Fetched Properties in the CoreData Programming Guide.
Here is how it is done:
You set up a to-many relationship from Goal to Item in the model editor. Don't use any ids, foreign keys etc. This is old-fashioned database thinking - you can forget about it. Here we are only dealing with an object graph. The database layer is just an implementation detail for persisting the data.
Make two more relationships in entity Goal to itself: a to-one called parent, a to-many called subGoals. Make them the inverse of each other. Simple!
QED is correct, you can create a to many relationship on goal (call it subgoals) as well as a to-one relationship on goal (call it parentGoal) and set them as inverses to each other.
Then create another to many relationship (call it items) on the goal entity, with the inverse being a to one relationship on the item entity (call it goal). Then you're all set. You don't need to link items with a unique id, just add them to the items relationship.
Also note that if you did want to give items a unique id, do not use the objectID. The objectID should only be used as a temporary id as they are not guaranteed to remain the same. In fact they will change if you ever do a Core Data migration.
One way, though not really great, is to create a another entity, say subGoal, and each goal has one subGoal and each object of subGoal has many goal.
So, I have two tables InventTable (for inverntory) and MyCartTable. I want to connect this tables so when I chose some item or items in InventTable to show in MyCartTable's grid. MyCartTable fields are ItemNumber, ProductName, PartyID;
Assuming you are working with AX 2012:
On your MyCartTable, remove the itemNumber field.
Open an other AOT windows go to Data Dictionary - Extended Data Types and locate the itemId data type. Drag and drop this data type on your table. AX will ask if you want to add a foreign key relation. Click yes, this will add a relation to the InventTable to the relations node of your table.
Now on your form, set the JoinSource property of your MyCartTable to you inventTable data source.
If you are having trouble making this work, create a new form with only those two datasources and a minimum amount of controls (like just 2 grids), this allows you to test this more easily.
I have this one to many relationship entities. An NSFetchedResultsController was used for a table view to display list of teams. This part I understand and it works fine. Now in this teams table view if one selects a team, another table view will display list of members.
Currently I use an array to hold the objects from the members set, like so:
NSArray *membersList = [NSArray arrayWithArray:[aTeam.members allObjects]];
But this second stage is not clear to me. Should I need to do another NSFetchedResultsController using the selected team name as a fetch predicate for the members list table view instead of expand the fault as I did above?
If you like to track changes in those items (Members), or the data set is very large, you should use a FRC.
If your data is not updated from an external source, and is relatively "small" you could just use the relationship as your datasource.
The FRC is made for you to track changes and access your data in an efficient way (fault and un-fault objects by need, batch fetching ...).
I have a similar challenge to this post: Batch insert/update with entity framework from a couple years ago, I was hoping that the story may have changed since then.
In short, I am running a RESTful service, and as such I'd like a PUT to be document-oriented and take an object along with a collection of child elements in. The child elements have a unique string that I can use for determining existence.
Unlike the referenced poster, I don't have a query requirement; all I want to do is be able to take in a collection of my child elements and perform an insert on the child table for any that aren't already there, and an insert or delete on the many-to-many table to account for the current state of the collection. Ideally, with some efficiency. I realize that I might end up doing this as a sproc, I just wanted to see if there's an EF-native way that works first.
To do this you must either know which items are new or you must query DB first and merge your received items with loaded items. EF will not handle this for you. Also be aware that there are still no batch modifications. Each insert, update or delete is executed in separate roundtrip to database.