When I create a class with OrientJS Class API, e.g. db.class.create('Story', 'E');, it creates automatically multiple clusters depending on how many CPU cores it has at the server side. This is the desired behavior.
But when creating an abstract class, it has to pass something to the cluster parameter. If null is used, i.e. db.class.create('Category', 'V', null, true);, it creates a class in cluster [-1]. I searched around but didn't find any statement about cluster -1. It seems like a special cluster because several classes can have the [-1] at the same time.
How can I create an abstract class but still have it distributed to multiple clusters?
Answer the silly question myself.
An abstract class will have no records in it, therefore cluster distribution is an irrelevant topic for an abstract class. Cluster [-1] is a dedicated dummy class for all the abstract classes.
It is not documented but a valid point, that assigning null to the cluster parameter when creating an abstract class with db.class.create. Because in the SQL statement construction code of OrientJS:
if (cluster) {
query += ' CLUSTER ' + cluster;
}
Related
I made a concurrent system which has a critical section which involves read and write access to a TXT file.
First, an Auctioneer class creates a TXT file and writes the number 50 to it. The Auctioneer then allows the next node, one of three instances of the Bidder class, to open the file and change the current bid. The bidder class then allows the next node, another bidder to bid, then another bidder, and then that bidder allows the Auctioneer to look at the file.
I allowed the nodes to take turns using server sockets. Each node waits for access using the ServerSocket.accept() method, and allows the next node to enter its critical section by creating a Socket object with the socket that ne next nde is listening on.
Each of these nodes run independantly in seperate java environments and only communicate with server sockets.
Each node of the ring relies on the previous node because in order for that node to access the resource, the previous node needs to pass the current node the token. I'm unsure on how I would represent that kind of relationship in a UML compliant way.
It is of my understanding that class diagrams should not include several instances of the same class such as the example below with 3 bidders.
Is this the correct way to represent the relationship which I have described? If not, which way would be better/UML compliant?
Class diagrams, as the name suggest represent classes of objects and not individual objects, i.e. instances of these classes. Moreover, a class diagram is structural: it does not tell how objects interact or wait one for another, but how classes relate.
In tour case the class diagram would therefore represent one bidder class. To represent a concrete example with instances and how they relate, you could consider an object diagram. There you could very well represent different instances of the same class.
However, if you’re interested in the interactions between classes (e.g. the tokens they exchange), you’d better consider an interaction diagram such as the sequence diagram.
C# 9 introduces record reference types. A record provides some synthesized methods like copy constructor, clone operation, hash codes calculation and comparison/equality operations. It seems to me convenient to use records instead of classes in general. Are there reasons no to do so?
It seems to me that currently Visual Studio as an editor does not support records as well as classes but this will probably change in the future.
Firstly, be aware that if it's possible for a class to contain circular references (which is true for most mutable classes) then many of the auto generated record members can StackOverflow. So that's a pretty good reason to not use records for everything.
So when should you use a record?
Use a record when an instance of a class is entirely defined by the public data it contains, and has no unique identity of it's own.
This means that the record is basically just an immutable bag of data. I don't really care about that particular instance of the record at all, other than that it provides a convenient way of grouping related bits of data together.
Why?
Consider the members a record generates:
Value Equality
Two instances of a record are considered equal if they have the same data (by default: if all fields are the same).
This is appropriate for classes with no behavior, which are just used as immutable bags of data. However this is rarely the case for classes which are mutable, or have behavior.
For example if a class is mutable, then two instances which happen to contain the same data shouldn't be considered equal, as that would imply that updating one would update the other, which is obviously false. Instead you should use reference equality for such objects.
Meanwhile if a class is an abstraction providing a service you have to think more carefully about what equality means, or if it's even relevant to your class. For example imagine a Crawler class which can crawl websites and return a list of pages. What would equality mean for such a class? You'd rarely have two instances of a Crawler, and if you did, why would you compare them?
with blocks
with blocks provides a convenient way to copy an object and update specific fields. However this is always safe if the object has no identity, as copying it doesn't lose any information. Copying a mutable class loses the identity of the original object, as updating the copy won't update the original. As such you have to consider whether this really makes sense for your class.
ToString
The generated ToString prints out the values of all public properties. If your class is entirely defined by the properties it contains, then this makes a lot of sense. However if your class is not, then that's not necessarily the information you are interested in. A Crawler for example may have no public fields at all, but the private fields are likely to be highly relevant to its behavior. You'll probably want to define ToString yourself for such classes.
All properties of a record are per default public
All properties of a record are per default immutable
By default, I mean when using the simple record definition syntax.
Also, records can only derive from records and you cannot derive a regular class from a record.
I'm coming from Neo4j and evaluating OrientDB, and I had a quick question about classes - do they have to exist prior to inserting a record? That is, in Neo4j there's the 'MERGE' command, which will update or create a node if it doesn't exist. Classes seem roughly equivalent to Neo4j's labels, and if a label doesn't exist when performing a MERGE, it will be created. Is there similar functionality in OrientDB? Currently when I try to insert a record whose class doesn't exist, OrientDB throws an exception, "Class SOME_CLASS not found in database".
I've been reading through the docs trying to get a handle on the various data models available, but I can't find anything explicit on this issue. One thing I tried was to add a cluster, and then insert a record with a class that does not exist. This worked, and in OrientDB Studio, under 'DB', I see the cluster with number of records equal to '1'; however, the class of that new record does not appear under 'Schema'.
If dynamic class creation of this sort isn't possible, is it acceptable to check if a class exists in the schema, and if not, create it, and then proceed with creating the record? A different question is, if it's acceptable, is it good to do this, or should I always define the schema manually?
If you use one of the CREATE commands, then the object is placed in a default class; for example:
CREATE VERTEX
Created vertex 'V#9:0 v1' in 0.047000 sec(s).
(In this case, the class is V.)
And of course if you use the INSERT INTO ... form, then you have to specify a class.
So perhaps your first question boils down to whether it is possible to change the class of an OrientDB vertex or edge.
It is possible to change the parent class of a vertex -- see
http://orientdb.com/docs/2.1/SQL-Move-Vertex.html -- but there are important caveats.
To test whether a class exists programmatically, see e.g. this SO entry:
Check if class exists or not in orientdb
This gives a Java example, but a similar approach is possible using other supported languages.
As to the wisdom of changing the class of an entity dynamically -- perhaps the safe answer is that if you can achieve whatever you want using a property label, then use labels.
I'm writing a soft in which various actors concurrently create portions of a same graph.
Nodes of the graph are modeled through a class hierarchy, each concrete class of the hierarchy has a companion object.
abstract class Node
class Node1(k1:Node, k2:Node) extends Node
object Node1 {
def apply(k1:Node, k2:Node) = ...
}
class Node2(k1:Node, k2:Node) extends Node
object Node2 {
def apply(k1:Node, k2:Node) = ...
}
...
So far so good.
We perfom structural hashing on the nodes on creation.
That is, each companion object has a HashTable which stores node instances keyed under their constructor arguments, this is used to detect that an instance of a given node class with the same subnodes already exists and to return that one instead of creating a new instance. This allows to avoid memory blowup, and allows have a node equality test that takes constant time (reference comparison instead of graph comparison). Access to this map is protected using a scala.concurrent.Lock.
Yet the problem is that the Lock operate at jvm thread level, and that depending on how actors are coded, they can either be allocated on their own jvm threads, or instead be interleaved with several other actors in a same JVM thread in which case the structural hashing ceases to work (i.e., several structurally identical nodes can be created, and only one of them will be stored in the cache, and the structural equality will cease to work).
First, I know that this structural hashing architecture goes against the actor share-nothing philosophy, but we really need this hashing to work for performance reasons (constant time equality brings us an order of magnitude improvement), but is there a way to implement mutual exclusion on shared ressources with actors that would work at actor level rather than jvm thread level?
I thought of encapsulating the node companion in an actor to completely sequentialize access to the factory but this would imply a complete rewrite of all the existing code, any other idea?
Thanks,
If you have shared mutable state, have a single actor which mutates this state. You can have other actors read, but have one actor that does the writes.
I have a requirement of creating java classes dynamically and make it accessible different jvms across the network. I tried to use reflection and javassist tool,but nothing worked. Let me explain the scenario
we are using Coherence distributed cache. It has a power of doing aggregation/filtering in parallel across the cluster. For example if a class has [dynamic class] has amount variable and getAmount/setAmount methods. Then if we execute COHERENCE queries, it will start process in parallel across the cluster.
I tried to create classes at run time by using javassist and reflection. I am able to access it from single JVM, but when I tried to access the same class from other jvm [through coherence cluster]. I am getting exception of class not found [as remote jvm is not having idea of this class].I can over come this by creating same class dynamically on remote jvm also and access the methods. But coherence in built methods/functions are not able to find the class.
could some one help me on this matter
A new class that gets created must be available to all nodes of the cluster. It means that the newly created bytecode must get on each node JVM's classpath/classloader. The simplest approach in my mind would be to put the generated classes on a shared network drive and have all JVMs point to that shared network location in their classpaths. Each time a JVM finds a reference to the new class it should load it dynamically from the network share.
You could copy the byte array that was created by javassist and send this byte array over the wire and load this byte array by a custom ClassLoader. This way, the class will be represented on all JVMs.