Is there a difference between saving a node, which is an instance of a class that inherits Node class, with save method and saving a node using the query builder in GQLAlchemy?
Also, is there any difference between node.save(db) and db.save_node(node)?
Related
I am not able to understand why Flutter objects are immutable. I tried it in the Flutter docs but they weren't that helpful. If anyone can help me with this, I'll be thankful.
Also, I just started flutter 2 days ago and it's awesome.
From https://api.flutter.dev/flutter/widgets/StatefulWidget-class.html
StatefulWidget instances themselves are immutable and store their
mutable state either in separate State objects that are created by the
createState method, or in objects to which that State subscribes, for
example Stream or ChangeNotifier objects, to which references are
stored in final fields on the StatefulWidget itself.
The framework calls createState whenever it inflates a StatefulWidget,
which means that multiple State objects might be associated with the
same StatefulWidget if that widget has been inserted into the tree in
multiple places. Similarly, if a StatefulWidget is removed from the
tree and later inserted in to the tree again, the framework will call
createState again to create a fresh State object, simplifying the
lifecycle of State objects.
A StatefulWidget keeps the same State object when moving from one
location in the tree to another if its creator used a GlobalKey for
its key. Because a widget with a GlobalKey can be used in at most one
location in the tree, a widget that uses a GlobalKey has at most one
associated element. The framework takes advantage of this property
when moving a widget with a global key from one location in the tree
to another by grafting the (unique) subtree associated with that
widget from the old location to the new location (instead of
recreating the subtree at the new location). The State objects
associated with StatefulWidget are grafted along with the rest of the
subtree, which means the State object is reused (instead of being
recreated) in the new location. However, in order to be eligible for
grafting, the widget must be inserted into the new location in the
same animation frame in which it was removed from the old location.
Performance considerations
There are two primary categories of
StatefulWidgets.
The first is one which allocates resources in State.initState and
disposes of them in State.dispose, but which does not depend on
InheritedWidgets or call State.setState. Such widgets are commonly
used at the root of an application or page, and communicate with
subwidgets via ChangeNotifiers, Streams, or other such objects.
Stateful widgets following such a pattern are relatively cheap (in
terms of CPU and GPU cycles), because they are built once then never
update. They can, therefore, have somewhat complicated and deep build
methods.
The second category is widgets that use State.setState or depend on
InheritedWidgets. These will typically rebuild many times during the
application's lifetime, and it is therefore important to minimize the
impact of rebuilding such a widget. (They may also use State.initState
or State.didChangeDependencies and allocate resources, but the
important part is that they rebuild.)
"Flutter objects" is quite broad. There are different kinds of objects.
State and widget are split and they have different lifecycles. Immutability is used for performance reasons. If the widget needs to change, create a new instance set up accordingly.
It's quicker to check if two instances are identical than if their state is the same.
This is one of the reasons const is used often. It ensures that identical instances are used if the constructor parameters are the same.
From the docs linked to above
Use const widgets where possible. (This is equivalent to caching a widget and re-using it.)
Immutability is the cornerstone of many programming languages and using immutable data can be more efficient flutter Take this advantage to rebuild the immutable view tree for every frame
In general, we should confide rebuilding to the subtrees that actually change
The widget tree is an immutable description of the user interface. How can we rebuild part of that without reconstructing it from the root? Well, in truth, the widget tree is not a materialized tree structure with references from parent widget to child widget, root to leaf. In particular, StatelessWidget and StatefulWidget don’t have child references. What they do provide are build methods (in the stateful case, via the associated State instances). The Flutter framework calls those build methods, recursively, while generating or updating an actual runtime tree structure, not of widgets, but of Element instances referring to widgets. The element tree is mutable, and managed by the Flutter framework.
So what actually happens when you call setState on a State instance s? The Flutter framework marks the subtree rooted at the element corresponding to s for a rebuild. When the next frame is due, that subtree is updated based on the widget tree returned by the build method of s, which in turn depends on current app state
import com.codename1.ui.tree.Tree;
import com.codename1.ui.tree.TreeModel;
Upon detecting a delete action from my tree ActionListener,
I delete the path on disk.
FileSystemStorage.getInstance().delete(node.getPath());
Then attempt to refresh the tree where there is one less element in the curr node.
tree.expandPath(true,(Object[]) (node.getNodeParent().getNodesOnPath()));
Can you please provide a working example of delete a single leaf (file) and then refresh the Node Parent
My approach does not work.
If I manually tap on the Node Parent twice, I see the file id no longer displayed as expected.
Thanks in advance.
Once it's shown the tree won't refresh unless you refresh the whole thing. Only hidden nodes take events into account so if you fold and reopen it will update. In the case of deletion you can just use something specific to the file and remove the specific node components from their parents directly which is a bit of a hack.
Alternatively you can refresh the entire tree which is what we do for the GUI builder by setting a new instance of the model. In the GUI builder that's practical because the tree is always expanded. It might be a bit painful for your implementation.
I am implementing a depth first tree traversal code a large tree. It's single traversal process can span several days because of the long processing time at each node and in between the system might crash or shutdown.
Therefore I want to make the whole process resumable if it the process stops in between for some reason. For that reason I am planning make the whole process backed by persistent datastore which essentially stores the state of the process.
As I figured out that for depth first traversal I will need a Stack type of data structure and which can be realized through a linked list type of array implementation. So my question is if there is some datastore which provides the ability to persist large array to maintain the order of the entities to represent a stack by it. Or if there is some other way through which I can maintain the state of my traversal in a persistent storage.
Thanks.
IMHO: You can implement a custom class of stack behavior using link list. This custom class should be serializable. Storing the state of object intermittently. So even when the system crashes you will loose some data and recreate the complete structure by de-serializing the object from persistent store.
How can I either reload a whole tree and/or a single node allong with all childs of these node from the scope of the node.
The Single-Node currently this is done by expanding but now there is the need for a reload button for the whole grid and for the selected node. I looked at the nodeinterface there is is nothing useful like a reload. The node are using a automodel at the moment, meaning no explicit model is created.
revished edit
I also tried to call removeAll() on a treestore and also removeAll() on the tree. The first calls the reader method for each removed node with the node itself as param which then result in a error cause there server answer all the invalid request with a empty result. The second removes all but also with errors.
Any help is appreciated!
For your second question:
You might try call the removeAll() of the tree instead of the store.
struct node
{
void *data;
struct node *link;
};
Given such a structure we call it as generic linked list.what is the use of such a list in terms of its real time application use.
It's genericness allows you to create some (tested and reliable) library code around it, which can then be reused.
Of course it's not typesafe this way, that's why C++ introduced (among other things) generic template classes.
As for the use of a linked list per se: you use it where you want to store and retrieve a variable number of similar objects. Typically you don't know the number of the objects in advance and you are fine with getting them in the order you stored them. It's also quite efficient to delete an object from a linked list (once you have a pointer to its list entry).
You have a service which accepts requests from multiple applications and provides handle to each of them. The service can maintain the contexts per request in a linked list and when its done serving them delete the node from the list. A empty linked list in that case would mean no application has registered to the service.
For Eg, Consider the service built over SIP stack and multiple applications like IM, Presence information can register with the service which uses the SIP stack for signalling. Now the service maintains the data pertaining to each of the application in a linked list(well that is again a question of design but lets assume we have a limit to serve 5 applications). The SIP response has to be redirected to the application sending the request and say you hold the callback pointer as one value of the node it is simple to call it once you find the corresponding node for the response.
Each node saves lot of information about every application and uses it for sending back the response to the application.
Probably you may want to have a look at this.
what is the use of such a list in terms of its real time application use
If all you have is that definition and a pointer to the head of the list, then its only good for creating a arbitrary stack of objects. This is because to do anything except add or remove an object to the head of the list you have to iterate through it. Even with this limited "efficiency", such a list has its uses e.g. as a cache for unused heap objects that you are going to recycle to avoid mallocs.
If you also have a pointer to the tail of the list, you can add objects to either end in O(1) time. This means you can use it as a queue.
If each item has a pointer to its predecessor as well as successor, you can also insert/delete items from any point in the list in O(1) time. Of course, you still need to find the object which might involve a linear scan.