Because nodes are immutable and every time new instances are created my references become stale. What's the best approach to handle this? I am refactorting to move class definition one level up. First I am adding it to the grandparent node but then my reference to class definition node is stale and I cannot use it.
var nodeExpression
var nodeMethod
var nodeClassDef
When I modify nodeExpression a whole new world is generated; how can I quickly get the matching nodes in that new world for nodeMethod and nodeClassDef?
Take a look at creating SyntaxAnnotations on the nodes you want to find after changes. A convenient way to do this is through the TrackNodes() extension method on SyntaxNode.
You can provide a list of nodes, and then find them after a re-write using GetCurrentNodes().
Related
I have linked list in Realm DB like
ABCD
Each item is Realm object like
{name,next item}
So if I change list on device 1 offline to
ACBD
and on device 2 to
ADBC
and sync after that I get synced DB but wrong cycled list
A -> D -> B -> D .....
How can I solve this problem?
Is there possibility to get synced objects after sync on clients and to correct lists before realm Results notifications will be launched?
Update.
I also tried to use such model for hierarchical lists
class MList: Object {
dynamic var name = ""
let items = List<MItem>()
}
class MItem: Object {
dynamic var name = ""
let subitems = List<MItem>()
}
I have used data
A
B
1.
A
-B
2.
B
-A
After sync but list lost all items. So such data struct is unsuitable for my task.
Alright, I see the problem.
Manually maintaining a linked list structure unfortunately won't work, because Realm sees each link update as a regular property update without knowledge about the item's position in the list. Therefore the list updates cannot be merged in the expected way when multiple participants update the list, and the result will be duplicates, cycles, or leaked objects.
Instead, I suggest you use Realm's built-in list type, which will merge correctly. You will still have a problem related to the parent field in your data model, whereby if two participants change the value, the last one to do so will "win". I'm not sure what your exact use case is, so this may or may not be fine. Notably it probably won't be fine if you perform tree rotations, in which case you will end up leaking objects from the graph or creating unexpected cycles.
The best long-term solution is for Realm to introduce a proper CRDT tree type, but so far there hasn't been demand for this. If trees are a fundamentally requirement in your data model, I suggest creating a feature request for CRDT trees in our GitHub repository.
Can you use Realm's own lists? They have quite an elaborate merging logic that supports element moves/reorderings: https://realm.io/docs/javascript/latest/#list-properties
Now I have the model
class MList: Object {
dynamic var name = ""
dynamic var firstItem: PLItem?
}
class MItem: Object {
dynamic var name = ""
dynamic var next: PLItem?
dynamic var parent: PLItem?
}
I use "next" to order list and "parent" to create the tree structure.
I have a model as follows:
class SomeModel(ndb.Model):
parent = ndb.KeyProperty()
someint = ndb.IntegerProperty(default = 2)
sum_of_child_some_int = ndb.IntegerProperty()
The parent property is either nothing (in the case of a top level parent) or is a Key pointing at another SomeModel entity.
My question is, what is the most efficient way of calculating the sum of all the someint's of all children of a SomeModel parent? It is recursive, so a child can itself have a child, and the someint would also need to be counted.
I see that it can be done at write - simply write to the entities parents recursively. But can it be done at read, or is that always going to be too expensive?
If you don't want to put that number at write time, you could use an ancestor query to get all the children of a given entity and extract the someint property. If you are going to do this, I think the most efficient way would be to use projection queries.
Just remember that if you don't write that sum when you put the entity, you will have to make the sum every time it is requested (although you may get a cached result), which sounds a bit wasteful. Memory is cheap, and adding another property updated at write time seems like the best idea to me.
By the way, maybe you don't need the parent as a KeyProperty, an ancestor may be a better way to do it.
Short Description
I need to build a non-binary tree (language doesn't matter for now, but preferably in C++) from a list of items that do have dependencies to each other, but non-recurring and not cyclic.
The data for the nodes are read from a file and incrementally inserted into the tree.
The troubling part is how to handle those nodes which do not have parent-nodes yet that fulfill the dependency of the inserted node.
Detailed Description
Rough Outline
The assignment is easy: represent a bunch of Tasks and Subtasks in a non-binary tree.
This assignment would be quite easy to understand and implement, if not for a tiny condition: the list of Tasks has to be generated incrementally, so do the nodes in the tree.
Scenario
The Tasks are generated asynchronously and have to be added into the tree once the data to a certain Task is received.
This is "simulated" by reading a csv-file which has a certain Task in each line with some data, the most important ones being the PID and PPID attributes.
After a line is read and parsed, a Task is being created and inserted into the tree.
The tree should automatically resolve the dependencies following two simple rules:
Only show the node when the dependency is met (namely when a parent-node has been inserted before), but memorize the (now orphaned) node.
Whenever a Task(node) is added, check if it's a parentnode of one of the above meantioned orphaned ones and reconcile the nodes if rule #1 isn't infringed while doing so.
Please disregard the faulty logic behind this scenario: Normally, there can't be any SubTask without a ParentTask existing (at least in monolithic kernel designs).
And while the List of Tasks certainly do contain the ParentTasks needed to model the tree, it is unknown when the ParentNode-Data is read and inserted into the tree.
Desired outcome
Below is a figure showing the "raw data", a list of (unsorted) Tasks which has been created incrementally while adding one Task after another to the list.
The tree represents the subset of Tasks which has been inserted so far:
Please keep in mind that the tree is completely "naked" until the Tasks with the PIDs 1, 2 and 3 are inserted, because the other nodes are dependent of them.
What I did so far
I've written a Qt-C++ Code with three rough components:
TaskTree which holds a Root-Node (a node without any task-data)
TaskNode which has a field to hold the task-data and a QList<TaskNode> which is, in simple terms, a vector of TaskNodes to reference childnodes
Task has the related attributes (like pid and ppid)
It is no problem to insert a TaskNode if the parentnode already exists.
This only works though in a perfect world, in which the Tasks are sorted upon their respective dependencies AND there's a determined amount of Tasks to be added.
I don't have to tell you that such a scenario is highly unlikely though, so the tree creation has to memorize any orphaned node (which is a node that doesn't have a parent yet, duh).
I've tackled this "memorization" in different ways, but failed alltogether because I couldn't wrap my head around the algorithms behind it.
The two most promising thoughts I had were these:
Insert every orphaned node into a vector. Upon inserting a parentnode, check if it has children in the Orphan-Vector and reconcile. Do this recursively for the newly created subtree to match all possiblities.
Assign the PPID to the tree's RootNode, being 0 for the most top one. When an orphaned node appears, create a new TaskTree, assign the PPID of the orphan to the newly created tree and add the orphan to it.
This creates subtrees which can be quit intricate themselfs if several orphans match one of the trees. After each inserted Node, try to reconcile the subtrees to the root-tree.
Unfortunately I had to give up continuing those two concepts due to several spontaneous SIGSEGV's and other problems occuring because of the recursions etc.
So in the end I'm here trying to find a way to actually make this work without cutting down the complexicity of the problem through assumptions and other cheats...
Do you guys and gals have an idea which algorithm I could use for this problem or what category of problem this even is?
Approach 2 is the right one to take. The pieces that you are missing are that you need an unordered_map called node_needed that maps as yet unseen parent nodes to a vector of child trees that are waiting for it. You need a similar one mapping node_seen to the associated tree for nodes that have been seen.
Then when you see a node you perform the following:
Create TaskTree with only this node.
Add this TaskTree to the node_seen map
If this node's ID is in the parent_needed map:
Add each tree in the parent_needed map to this tree
Remove this node's ID from the parent_needed map
If this node has no parent:
Add this node's tree to the root tree
Else if this node's parent ID is in the node_seen map:
Add this node's tree to the parent tree
Else if this node's parent_ID is in the parent_needed map:
Append this node's tree to the parent_needed vector
Else:
Create a vector containing this node's tree
Add a mapping from this node's parent ID to that vector in the parent_needed map
Assuming no bugs (HAH! Bugs are part of life...), this should work.
After some deliberate design changes, I've come up with - what I think - the easiest way to implement this:
InsertTask(Task newTask)
{
Task parentTask = searchTreeForParent(newTask->ppid)
If (parentTask not found)
{
parentTask = treeRootNode;
}
If (treeRootNode has children)
{
For (every children in treeRootNode: child)
{
If (child->ppid != treeRootNode->pid AND child->ppid == newTask->pid)
{
newTask->addChild(child)
treeRootNode->remove(child)
}
}
}
parentTask->addChild(newTask)
}
The algorithm behind it is pretty easy: You add the new Tasks to the root node if there is no parent node yet and at the same time check if the newly added Task has potential children in the root node (because those orphaned ones were added to the root node before).
So if you actually insert all the Tasks to fulfill the dependencies, you end up with a complete and valid tree.
If you don't supply all the parent nodes, you end up with some of the branches being complete and valid and a bunch of orphaned ones in the root node.
But that's no problem because there is an easy trick to differenciate between a complete branch and orphans: just check if the ppid equals the root node's pid and voila, you output only those branches that are complete.
I am using a static class in my application. It basically uses an access database, and copies itself to various lists.
When the user modifies some data, the data is updates in the list, using LINQ, if there is no entry in the list for the modification then it will add a new item to the list.
This all works fine.
However on the 1st data interrogation, I create the original list, basically all records in the users table, so I have a list lstDATABASERECORDS.
What I do after populating this list I do lstDATABASERECORDSCOMPARISON=lstDATABASERECORDS
this enables me to quickly check whether to use an update or append query.
However when I add to lstDATABASERECORDS a record is added in lstDATABASERECORDSCOMPARISON too.
Can anyone advise?
You are assigning two variables to refer to the same instance of a list. Instead, you may want to try generating a clone of your list to keep for deltas (ICloneable is unfortunately not that useful without additional work to define cloneable semantics for your objects), or use objects that implement IEditableObject and probably INotifyPropertyChanged for change tracking (there's a few options there, including rolling your own).
There's nothing built in to the framework (until EF) that replicates the old ADO recordset capability to auto-magically generate update queries that only attempt to modify changed columns.
I have a given model in .ive and the problem is that I'm trying to rotate a single node out of the whole tree model (existing in the .ive file). Is that possible? How can I do that?
Sure, it can be done.
You first have to find the nodes that you want to manipulate. You should be able to do this by creating a subclass of osg::NodeVisitor, and using it to traverse the graph until you find the node you want to manipulate. If you've given the node a name, it can be simple to find the one you are looking for. If not, you'll have to figure out some other unique characteristics of the node, or just pull all nodes of a certain type and try them one at a time.
Then, once you have that, you can just save a pointer and manipulate it directly.
See tutorials:
https://www.movesinstitute.org/Sullivan/OSGTutorials/osgDOF.html
and
https://www.movesinstitute.org/Sullivan/OSGTutorials/osgUpdate.htm
You will have to find the node that corresponds with that subsection of the model. To do this you will need to identify something that is unique about that node (hopefully it has a name or something).
Once you have that node, you may need to break it off of the main tree, add a Transform of some kind (a PositionAttitudeTransform, probably) and then re-add your node as a child of the PAT.
Then you can modify the rotations in the PAT.
You might use a visitor like the find named node(s) visitor to locate the node you want.
Consider converting the .ive file to .osgt or .osg in order to see the structure (and hopefully node names) in the file.