I am developing an application that contains multiple features and each feature has multiple functions. I represented this as a tree but some functions use other functions which means a child can have more than one parent (if I am not wrong). How it is possible in a tree data structure? Can I access the child node from another parent's child node? If so how can I implement this? Can graphs help me with this issue?
If a node has more than two parents, your data structure is no longer a tree. E.g., to quote the wikipedia entry:
A node has at most one parent, but possibly many ancestor nodes, such as the parent's parent.
If you need a data structure where a child can have multiple parents, you should look into a (directed) graph.
a google search gives the answer that:
"Yes, you can have nodes have both “children” and “parents”. However that is no longer a tree structured graph, so you will not be able to use a TreeModel"
Original reference
Related
As far as I've read parents should store childrens data which would solve my problem simply because I could iterate through the tree, but I'm not able to come up with a solution that manages to do that in react.
To clarify:
My goal is to convert my JSX-Layout to a JSON-Object so that I can send it to my backend for further processing.
Currently each of the nodes handle the adding of a new child in themself. All nodes only know their immediate children.
The problem now is that I don't know how I could read the entire tree data structure.
For example: In Java I could simply add a child to a node by just accessing the node's reference and adding the new node to the list of childrens. Since I use functional components in React I'm not able to do that and probably need to pass down a event from the parent nodes to register new nodes from children but I simply cant wrap my head around it. I don't see how that is possible with React, but I'm certain that it's just me misunderstanding something or trying for too long.
Any help is appreciated!
TL;DR:
How do I manage state in trees so that I can access the whole tree and add/remove children to/from children and their descendants?
I tried to pass down an event from the parent through the whole hierarchy where every child would add its children but I'm not sure if that is correct since it seems really unclean.
If I'm understanding your question correctly, you want a way to traverse your tree. There are various ways to traverse a tree to generate a full depiction of its elements (to make a JSON object, for example), but I think you probably want to use in-order traversal. Here is a link with more details about some different tree traversal strategies.
If you're looking for a way to access a React component's children, you can read this article for inspiration.
I am setting up a branch-and-cut algorithm using the generic callback framework through the C API of CPLEX 12.10.
At each node, the separation problem is based on the current node LP and detects locally valid cuts, that if violated are added for every child node of the current node.
To my understanding, the information of a current node LP is not readily available in the generic callbacks. However, I would like to use cuts generated for a parent node, to generate better cuts in the child nodes.
Is it necessary to do book-keeping about which cuts are generated at all the nodes or can this information somehow be passed on using CPLEX functionality? If the only possibility is to keep track of all generated cuts, how can this book-keeping be made thread-safe, if CPLEX calls the callback from different threads and in different nodes?
There is no way to make CPLEX keep track of this information for you. You have to roll your own.
One way to do this is to implement a dictionary that maps a node's unique id (see CPXCALLBACKINFO_NODEUID) to the information you want to store along with that node. With respect to thread-safety you only have to protect the accesses to that dictionary. To do that, use a lock (pthread_mutex on non-Windows, CRITICAL_SECTION on Windows, for example) and lock and lookup or update operation on that dictionary.
I wrote a script that loads data from 2 tables.
Using this script I need to just match corresponding elements in these 2 columns.
I am using angular-ui-tree for managing columns, but can't come up with an idea how to visually and programmatically match corresponding elements between 2 trees?
Thanks
Not quite sure what is your problem here. I assuming by "matching visually" you do not mean you need some AI API to actually do visual match, so you just want to get objects that are in the same location in the UI tree?
Using $nodeScope (type: Scope of ui-tree-node) should give you that information, as the property of $nodeScope is something like "1.1.1" or "1.1.2" etc. So you can just parse the "parent" node to get all children belonging to same node.
Scope also has a method isParent(nodeScope) which can check if a certain node (that calls the method) is a parent of targeted node. Similarly Scope has isSibling(targetNodeScope) and isChild(targetNodeScope) methods to help you identify the relationships. As a general guide, you just follow the (array) of nodes in a (nested) loop and pick the elements or objects you need. You can pick the objects from both UI trees at the same time, so they should be from the same node at that point.
I am making an MEAN stack app and use Mongoose alongside Mongo. I am struggling with organizing my objects in database. All works as expected but I have a feeling that the way I am doing things is wrong, but can't seem to find any resources on the topic that could help me, thus I hope somebody with some experience can share it with me.
I use Mongoose to create several schemas, and there is one dilemma I am facing, concerning nested objects in MongoDB.
Let's say I have a model that looks like that:
ParentSchema:{
property1:String,
children:[{}]
}
So, property1 is just some string, 'children' is an array that will contain objects of type 'Child' with some other properties, but also another array (f.ex. 'grandchildren:[{]} ), this time with another type of objects (Grandchild).
Child and Grandchild have no schemas and do not exist outside of the Parent, and will most likely be unique to each instance of Parent, so two Parents would not be sharing a Child object.
In my app, I am able to use urls such as '/parent/:id1/Child/:id2/Grandchild/:id3', where 'id1' is an actual id of Parent that Mongo generates, while 'id2' is an index of Child object instance stored in Parents array. The same goes for instances of Grandchildren stored inside Child object.
I was thinking that maybe having separate schemas for all 3 objects, and just saving references to objects is the way to go, like this:
ParentSchema:{
prop1:String,
children:[{type:ObjectId, ref:'Child'}]
}
ChildSchema:{
prop1:String,
granchildren:[{type : ObjectId, ref: 'Grandchild'}]
}
GrandChildSchema:{
prop1:String,
prop2:String
}
..but was unsure, as for me it implies that Child and GrandChild instances would be shared between different parents, however it seems easier to work with.
To sum up, I would like to know is:
which approach should I choose and why: first, second or maybe some other that I do not know about yet.
If I were to choose the second approach, should I create a separate API route for each of the objects?
How would I go about creating then? My wish is for the process to look like so:
Start creating Parent -> start creating first Child -> create some Grandchildren ->
finish creating Child -> start creating second Child -> ... -> finish creating Parent.
I apologize if the question is somehow weird, I will try to clarify as best as I can if required.
I would go with the second approach for a couple of reasons:
Schemas have better readability in my opinion.
They allow for data validation which you lack in the first approach.
Please note the answer below is primarily opinion based.
For the API design:
I think its really up to you as to which paths to expose to the consumer, since you've stated Child and Grandchild do not have the right to exist without a parent - I think your routes are fine as they are.
And finally - your process for creating these entities look fine to me. I would do the same thing myself.
I'm interested in using db4o as my persistence mechanism in my Desktop application but I'm concerned about a couple things.
1st concern: Accidentally clipping very complex object graphs.
Say I have a tree with a height of 10 and I fetch the root, how does it handle me storing the root object again?
From my understanding, it doesn't fetch the entire tree it fetches the first 5 referenced layers.
So.. If I make a trivial change to the root and then store it, will it clip away the nodes further down the tree, in essence deleting them.
If not.. how does it handle this?
2nd concern: Extracting subgraphs in a larger object graph
Using my tree example from above... If the database contains 1 massive tree can I query for a single node within it? Since .store was called only once, does my database think it contains only 1 "record"?
Thank you.
You have to be very careful, because two things can happen: you can pull whole db into memory, or just partial graph (rest of objects will be null).
In db4o there's notion of Activator and Update depth, which can be configured upon dbv40 configuration, or when objects are fetched. Its the way you tell db40 how deep you want him to go when fetching referenced objects. Check db4o web site, there's documentation about it:
http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Activation
http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Update_Depth
DB4O's Transparent Activation should resolve most of the fears you've expressed here.