z3 returns the number of unsat clauses for a Max-SMT problem together with only one model. I wonder if I can list them all (e.g. using API).
As mentioned in this question, you can use the generated model to add a constraint to prevent the generated model and run the solver again. In your case however, I believe you will also need to check the number of constraints that are broken, after generating a new model, to ensure that you don't break your optimality constraints.
Related
I would like to use Z3 to reason about a configuration problem using some data from a relational database containing physical properties of materials.
As suggested in this post, I could use an outer loop around the solver. But this works only for sorts with finite domains: I don't see how it would work on infinite domains.
I could represent the whole data tables by Z3 functions from primary keys to attributes, using the if-then-else construct, but the reasoning might use only a few rows in the table: it does not seem efficient.
Another approach would be to create a custom background theory solver that would determine the truth values of atoms by database lookup : has that been done before ?
Do you see some other ways to do it ?
It appears that I can't add a relationship unless there is already some data in some Entities that obey that relationship. Is this correct? I want to be able to set up my relationships and Labels first and then populate with data and have the data just use the relationships.
I am using:
MATCH (from:this_label),(to:that_label)
WHERE from.id = to.uuid
CREATE (from)-[:hasARelationship]->(to);
Basically, I want to be able to define a bunch of relationships on nodes of a certain label, even if those node-type do not yet exist. And then when some data of those nodes comes into the database it will hook up the relationships automatically.
It may be helpful to distinguish between the responsibilities of enforcing a constraint and fulfilling a constraint.
Neo4j allows for indices and constraints associated with labels. Indices and constraints created for a label are used to index and constrain the nodes that have that label. As of version 2.2.5, there is only one type of constraint: a uniqueness constraint for a single property. There have been talk about adding constraints for combinations of properties, and for relationships, but I don't know the status of these conversations.
The Neo4j schema constraints enforce something, but they will not fulfill, in the sense of changing your operations on the database to satisfy the constraint. If there were constraints enforcing that a node with label A may only be created if it has a relationship of type R to a node with label B, they would block your operation if it did not satisfy the constraint, but they would not satisfy it for you.
The best way to achieve this is a) to satisfy this requirement in your client application, or b) to create an extension for Neo4j. For an extension example, consider neo4j-uuid by Stefan Armbruster. It listens to transactions (using what's called a TransactionEventListener) and makes sure that any node that is created in the database has a UUID. This extension satisfies what could only be enforced by a corresponding Neo4j schema constraint (there are other differences, e.g., the constraint would be limited to the scope of a label).
A way to achieve your intention could be to either create an extension which listens to what you write to the database and satisfies your constraint, altering your operations if necessary; or, one which provides an invocation target in the server (a RESTful endpoint) that you can invoke whenever you want to create a node with a particular label. The extension would then create the node and other elements necessary to fulfill your schema. A downside to the former could be the overhead of listening to all your operations, a downside to the latter could be that it breaks your flow of interaction with the database to introduce a separate type of invocation (e.g., if you normally execute cypher statements and have to pause to issue a separate POST request and interpret the response before continuing).
If I understand you correctly, you want to use MERGE instead of MATCH.
MERGE (from:this_label) -[:hasARelationship]-> (to:that_label) WHERE from.id = to.uuid
If you are trying to create relationships without nodes, I guess that is not even possible in NEO4J. Infact, it wouldn't be possible in any graph in general.
It does not make sense to pre-populate your DB with relationships that connect to dummy nodes. Among the many reasons are these:
You would not be able to make any meaningful queries involving such relationships
Trying to fill in the dummy nodes later on with actual data may be a complex endeavor
It is very easy to created relationships right when they are needed. neo4j is a "schemaless" DB (except when you define uniqueness constraints, as #jjaderberg mentions). You can create a relationship of any type connecting nodes with any labels (or no labels) at any time. To keep things organized, you may choose to write your DB client code and Cypher queries to conform to your own conceptual "schema", but neo4j has no such a requirement.
I am using a "BatchInserter" to build a graph (in a single thread). I want to make sure nodes (and possibly relationships) are unique. My current solution is to check whether the node exists in the following manner:
String name = (String) nodeProperties.get(IndexKeys.CATEGORY_KEY);
if(index.get(IndexKeys.CATEGORY_KEY, name).size() > 0)
return index.get(IndexKeys.CATEGORY_KEY, name).getSingle();
Long nodeID = inserter.createNode( nodeProperties,categoryLabel );
index.add(nodeID, nodeProperties);
index.flush();
It seems to be working fine but as you can see it is IO expensive (flushing on every new addition - which i believe is a lucene "commit" command). This is slowing down my code considerably.
I am aware of put if absent and uniqueFactory. As documented:
By using put-if-absent functionality, entity uniqueness can be guaranteed using an index.
Here the index acts as the lock and will only lock the smallest part
needed to guaranteed uniqueness across threads and transactions. To
get the more high-level get-or-create functionality make use of
UniqueFactory
However, these are for transaction based interactions with the graph. What I would like to do is to ensure uniqueness of nodes and possibly relationships in a batch insertion semantics, that is faster than my current setup.
Any pointers would be much appreciated.
Thank you
You should investigate the MERGE keyword in cypher. I believe this will permit you to exploit your autoindexes without requiring you to use them yourself. More broadly, you might want to see if you can formulate your bulk load in a way that is conducive to piping large volumes of cypher queries through the neo4j-shell.
Finally, as general pointers and background, you should check out this information on bulk loading
When I encountered this problem, I just decided to go tyrant and force index values in my own. Can't you do the same? I mean, ensure uniqueness before you do the insertions?
If two scenarios can occur at the same time, does that (always/ever) constitute a third scenario?
My current thinking is that they are not necessarily exclusive (depends on the scenario). If you have two scenarios that could occur at the same time that they would only require a third scenario if the Given/When/Then steps do not merge implicitly or if one scenario takes precedence over the other.
This question has arisen whilst thinking about scenarios for what is essentially a form of injection in which Collections of objects get injected into another object ( https://github.com/jameskennard/mockito-collections ). So given the two scenarios "Class of object under test has a List of collaborators" and "Class of object under test has a Set of collaborators". Both could occur at the same time so a third scenario could be "Class of object under test has a List and a Set of collaborators". But it doesn't feel right, it's just too verbose, I think the Given/When/Then steps would be seen to merge implicitly. (Have a bad feeling I may have just answered my own question)
Anyone have any differing thoughts?
I think the key here is the behavior. The potential third scenario ("Class of object under test has a List and a Set of collaborators") that you're asking about is of course real but the behavior is already covered by the other two scenarios so I'd say there is no need to write another scenario.
If the combination of givens was to result in different behavior there would certainly be a third scenario but I believe the two you have cover the behavior you're looking to define.
At the moment, your sentences above are describing state rather than behavior.
What is the different outcome you get in each of the different contexts? I would expect something like this:
Given my CUT has five collaborators
When I do my thing with the class
Then it should use each collaborator in turn.
Given my CUT has five collaborators
And the fourth and fifth collaborators are identical
When I do my thing with the class
Then it should only use the fourth collaborator once.
That would illustrate the different behavior of the list (ordered) and the set (no duplicates).
If those two elements are truly beneficial independently, then yes, they're two separate scenarios. If they both have to be present for the class to have any value, I'd merge them into one:
Given my CUT has five collaborators
And the fourth and fifth collaborators are identical
When I do my thing with the class
Then it should use each collaborator in turn
And it should only use the fourth collaborator once.
An example of two simultaneous benefits might be getting cash out of an ATM, in which the cash is delivered and the account is also debited. You couldn't do either of those independently. Offering a receipt for the transaction would be a separate benefit, as it doesn't need to occur for an ATM to be of value. Hope this helps to make the distinction.
I'm calling a update SPROC from my DAL, passing in all(!) fields of the table as parameters. For the biggest table this is a total of 78.
I pass all these parameters, even if maybe just one value changed.
This seems rather inefficent to me and I wondered, how to do it better.
I could define all parameters as optional, and only pass the ones changed, but my DAL does not know which values changed, cause I'm just passing it the model - object.
I could make a select on the table before updateing and compare the values to find out which ones changed but this is probably way to much overhead, also(?)
I'm kinda stuck here ... I'm very interested what you think of this.
edit: forgot to mention: I'm using C# (Express Edition) with SQL 2008 (also Express). The DAL I wrote "myself" (using this article).
Its maybe not the latest state of the art way (since its from 2006, "pre-Linq" so to say but Linq works only for local SQL instances in Express anyways) of doing it, but my main goal was learning C#, so I guess this isn't too bad.
If you can change the DAL (without changes being discarded once the layer is "regenerated" from the new schema when changes are made), i would recomend passing a structure containing the column being changed with values, and a structure kontaing key columns and values for the update.
This can be done using hashtables, and if the schema is known, should be fairly easy to manipulate this in the "new" update function.
If this is an automated DAL, these are some of the drawbacks using DALs
You could implement journalized change tracking in your model objects. This way you could keep track of any changes in your objects by saving the previous value of a property every time a new value is set.This information could be stored in one of two ways:
As part of each object's own private state
Centrally in a "manager" class.
In the first solution, you could easily implement this functionality in a base class and have it run in all model objects through inheritance.
In the second solution, you need to create some kind of container class that will keep a reference and a unique identifier to any model object that is created and record all changes in its state in a central store.This is similar to the way many ORM (Object-Relational Mapping) frameworks achieve this kind of functionality.
There are off the shelf ORMs that support these kinds of scenarios relatively well. Writing your own ORM will leave you without many features like this.
I find the "object.Save()" pattern leads to this kind of behavior, but there is no reason you need to follow that pattern (while I'm not personally a fan of object.Save(), I feel like I'm in the minority).
There are multiple ways your data layer can know what changed and most of them are supported by off the shelf ORMs. You could also potentially make the UI and/or business layer's smart enough to pass that knowledge into the data layer.
Two options that I prefer:
Generating/hand coding update
methods that only take the set of
parameters that tend to change.
Generating the update statements
completely on the fly.