i am trying to make a subclass unique by applying a unique constraint on a db4o object's inherited field? Is it possible?
ex: class B inherits field f from class A and i need to make f unique only for class B.
As far as I know this is not possible. You only can make a field unique on the class it is defined on. In this case it's class A.
It's not possible to mark a field inherited from class A, as unique only for the subclass B.
Related
I have difficulty understanding this statement in DL:
∃R.∃S.C(a)
What does this proposition exactly mean?
Thanks in advance!
This means that the individual named a belongs to the concept ∃R.∃S.C. The concept ∃R.∃S.C represents the class of things that have a relation R with something that has a relation S with something that is in the class denoted by C. For instance, if R is the relation married to, S is the relation works for and C is the class of Public organisations, then ∃R.∃S.C represents all the entities that are married to something (or someone) that works for a public organisation. Then ∃R.∃S.C(a) means that the individual named a is such an entity.
Is it possible to add constraints on subgraphs? I have a tree type structure of items belonging to a category:
(cat:Category)<-[:OF_TYPE]-(item:Item {name:'foo'})
I want the name of each item that shares the same category to be unique, but item nodes of a different category should be able to have the same name. Can this be enforced with constraints?
Unfortunately currently there is no such functionality available in Neo4j.
You can only create contraints for whole database.
Alternatives:
Extension
You can create unmanaged extension that will register TransactionEventHandler. This one will be responsible for checking your specific domain constraints and reject invalid transactions.
Domain
You can alter your domain to make this available. For example - add DogCategoryItem label to each item under "dog" category. And then add separate constraint to DogCategoryItem only.
Note: I am not sure is it good or bad idead to have a lot of constraints in database (but my guess - nothing terrible should happen).
As FylmTM mentioned, this is not possible out of the box. However you can achieve this easily by having a compound property being a concatenation of the Category name and the Item name.
For example you can add a reference property on the Item node which should be unique for category name + item name concatenation
CREATE CONSTRAINT ON (i:Item) ASSERT i.reference IS UNIQUE
When you create an Item, you need to create this reference property value. As you will match anyway the Category node for creating the relationship, this is not a big deal :
MATCH (c:Category {name:"Category1"})
CREATE (i:Item {name:"Item1"})
SET i.reference = c.name + i.name
MERGE (i)-[:OF_TYPE]->(c)
If you try to create another Item with the same name in the same category, it will fails due to the Unique Constraint
I am trying to create a PFObject subclass in Parse that has a one-to-one relation to another PFObject in Parse, but I would like this relation to support any PFObject subclass. Currently, as soon as I create and save my first PFObject to Parse, whatever that PFObject is connected to is set as that relation's one and only accepted type, and creating a second object that connects to a different PFObject subclass for that relation generates an error.
Is there a way either to...
Specify the desired class that a one-to-one relation (i.e., really a pointer) should connect to? And if so, will it support connecting to subclasses of that specified class?
Create a one-to-one relation easily that supports any kind of PFObject?
Example:
For example, let's say I needed to create a subclass of PFObject called Zookeeper in addition to multiple subclasses of PFObject for various types of animals: Armadillo, Bear, Camel, etc. (and for reasons that we must accept, each animal has to have its own PFObject subclass rather than using a generic Animal class).
Then let's say that each Zookeeper is responsible for exactly one animal. To do this, I want to create a one-to-one relation on Zookeeper called animal so that I can specify a single animal object that each Zookeeper is responsible for.
I create multiple Zookeeper and multiple animals. I successfully save my first animal (an Armadillo) and my first Zookeeper object ("Alice") and my second animal (a Bear), but when I try to save my second Zookeeper object ("Bill") to Parse, I get the following error:
invalid type for key animal, expected *Armadillo, but got *Bear
I am not sure if this is exactly what you want, but could you:
Create an Animal subclass in Parse, with a text field called "type", and one column for each of the different types of animals (yeah, I know this is isn't that elegant).
The column matching the "type" column contains a pointer to the specific animal object, while the other columns are nil.
To get the specific animal object, you need to get the Animal object, look at the type column, and then look at the corresponding pointer column to get the specific animal object.
For example, the Zookeeper object contains a pointer to an Animal object. The "type" column of Animal object contains the text "bear". You then retrieve the object in the "bear" column of the Animal object, which is a Bear object. Does this meet your specification? Yes there is an Animal object, but there is still a notion of specific animal objects like Bear, etc.
What I ended up doing was saving the class name and object ID of the desired target object to my object rather than saving it as a pointer; so in the example above, that would mean creating the properties animalType and animalID on Zookeeper and using those properties to query the relevant animal with objectId = animalID. That way I don't have to create any new class types that are purely relational.
I have two entities A and B between which there is a 1 to n relationship (A-1---n->B). What I want to achieve is that whenever an entity A is recovered is also be automatically retrieved a specific entity B belonging to the relationship. I could think of is to create a subclass of NSManagedObject and modify it to achieve my goal but I do not know how to do that and whether it is the right solution.
You can get XCode to automatically generate an NSManagedObect subclass for you by going to the Editor drop down menu. Once you've generated the subclass, you can write any custom code into the generated subclass but it's often recommended to create a Category as if you need to regenerate the subclass it will wipe said custom code.
As for the retrieving of a specific entity B, you could have another relationship to entity B but this time just a 1 to 1 relationship (say "specialRelationship" for example) and tick the "transient" box (this just means that the data isn't stored in the persistent store, but is determined programmatically). In your Category, you can then write a custom accessor for specialRelationship which will programmatically choose the correct entity B to return.
If I had a Dog model and you can choose it to be 1 out of 3 of the Types called Small, Medium and Large. Should these Types be models themselves if I'm going to put logic in them? What would be the model design?
If Small, Medium and Large will each have unique methods but share common attributes you could have a base Dog model and then subclass each of the sizes like class SmallDog < Dog. Use single table inheritance on the dogs table by adding a type column that accepts values like "SmallDog", etc.
Will all the different types have a common interface but just differ in their logic?
If the interface is the same (i.e they all have the same function definitions) then I'd just have subclasses for each of the different types of dog that extend the original Dog model and have some kind of factory class that handles the creation of Dog models and automatically selects the appropriate class based on the type of Dog. By using the factory class with a common interface for Dog types the rest of the application does not need to care about the type of Dog and you can freely add/remove new types by simply modifying the factory class.