Let's create 3 vertices (with no relationship) [works fine]
graph.addVertex(label, "Master", "title", "master")
graph.addVertex(label, "Test", "title", 'abc')
graph.addVertex(label, "Test", "title", 'xyz')
Link master with abc [ works fine]
g.V().hasLabel("Master").addE("relation").to(g.V().has("Test","title",'abc'))
Link master with xyz [Fails]
g.V().hasLabel("Master").addE("relation").to(g.V().has("Test","title",'xyz'))
ERROR
Cannot UPDATE the record #59:3 because the version is not the latest. Probably you are updating an old record or it has been modified by another user (db=v2 your=v1)
This exception happens because you're running in a Multi Version Control Check (MVCC) system and another thread/user has updated the record you're saving. For more information about this topic look at Concurrency.
Is this the case?
If so, you can check this link
Hope it helps
Regards
Related
In the documentation from FMI the HTTP-body example for creating records using FMS16 Data API (REST) looks like this
{"data":
{
"field_1": "value_1",
"field_2": "value_2",
"repetitionField(1)" : "fieldValue",
"Orders::OrderDate.0":"12/22/2015"
}
}
The last attribute Orders::OrderDate.0 sets a value to a field on a related record and since the record don´t already exist it will be created.
My question focus on the .0 suffix of the attribute name. It looks to me like the 0 indicates a serial/identifier for on which related record the value should be inserted. This leads me to wonder if it is possible to create more then one related record in the same request that creates the parent record.
The below body returns error that the record does not exist, but why can one related record be created but not two?
{"data":
{
"field_1": "value_1",
"field_2": "value_2",
"repetitionField(1)" : "fieldValue",
"Orders::OrderDate.0":"12/22/2015",
"Orders::OrderDate.1":"11/11/2011"
}
}
Any clue if the above code should work? Am I missing something?
I am fully aware that I can (should) post several requests aimed at the related tables layout to create the related records. I just wish to know, since the .0 notation is in the documentation, does it should have a valid function?
Found this under the notes section in the doc you linked to:
"Only one related record can be created per create record call."
So there you have it. Looks like it behaves similarly to record creation from a portal, where you also can only create one related record at a time.
So I'm causing a conflict on purpose with the example of this site: http://guide.couchdb.org/draft/conflicts.html (Working with Conflicts).
Now there are two revisions and CouchDB decides with its own algorithm which revision to use but i would like to keep both revisions and merge them.
As an example: i got Phonenumber: 111 and Name: Jules on database A and Phonenumber: 222 and Name: Jules on database B.
Is it possible to create a new document which keeps all information from the old and the new revision?
Or a new field like "NewPhonenumber: 222" and the other fields Phonenumber: 111 and Name: Jules ?
I just want to keep both revisions no matter how.
I tried to write a View function but i just don't know how to grab the data from the conflicting database.
function(doc) {
if(doc._conflicts)
emit(doc._id, doc);
emit(doc._id, {oldNumber: doc.phonenumber, newNumber: doc.phonenumber, name: doc.name});
}
How can I replace "oldNumber: doc.phonenumber" with the number from the old revision?
Thanks!
The property doc._conflicts contains one or more conflicted revisions of the doc - you have to iterate over the list and grab the value you want.
If you do this in the view your conflict resolving will never be stored. You have to send the resolved version of the doc as new revision to CouchDB.
You can request the doc with its conflicts by using the query param ?conflicts=true (more in the CouchDB documentation) and store your decision as new revision.
Suppose I have an mobile app named APPO v1 which take resources from a REST API v1. There are about thousands of user at APPO v1
Now I am developing APPO v2 with API v2. Both api and app have new functionality and new fields in database. Some fields are modified too.
API v1 DATABASE SCHEMA:
{
"user_id": NumberLong(616),
"name": "XYZ",
"city":"Dhaka"
"password": "raw password: 12345678",
"gender": ""
}
API v2 DATABASE SCHEMA:
{
"user_id": "STRING HASH",
"name": "XYZ",
"address":"98/3 Circle road, Dhaka 1209"
"password": "MD5 HASH",
"NEW_FIELD": NumberLong(5)
"ANOTHER_FIELD": ""
}
Changes:
data type of user id is changed
Short city name replaced with address string
password format is changed
gender field is removed
some new field is added
How to handle the database ?
My solution 1: Separate DB by v1 & v2. Re-format the v1 and paste into v2
Problem with solution 1: All user will not update the app in a day. If a v1 user update their app to v2 they may loose the recent data. I have to make a synchronizer between two DB
My Solution 2: Since my app v1 takes raw password I have to keep this right away. I should marge the both SCHEMA
{
"user_id": NumberLong(616),
"user_id_hash": "STRING HASH",
"name": "XYZ",
"city":"Dhaka"
"address":"98/3 Circle road, Dhaka 1209"
"password": "raw password: 12345678"
"password_md5": "MD5 FORMAT",
"gender": ""
"NEW_FIELD": NumberLong(5)
"ANOTHER_FIELD": ""
}
Problem with solution 2: It will create huge garbage when the version will greater than 10 or more. At v10 i dont need v6,v5.......v1 Data
NOTE: Fields have nothing to do with REST model. All are example fields for such kind of situation
I am totally confused how to deal with that. I really appreciate your patient and your suggestion!
Thanks in advance !
i have a solution, if you don't want to denormalize the database. You can use bridge pattern for this problem. When you have same type of multiple problems/implementations(API v1 & API v2...etc), but client will be connected with only one implementation (ex. API v1 ), you need to implement a bridge object, which will understand, where to place the client, i mean required implementation. in technically, you have to write the business logic for each problem separately but only one REST Api is enough to redirect the client to that implementation. Thanks
I'm researching OrientDB in order to evaluate versioning capabilities of graph databases.
Each record in OrientDB has a #version property which increases every time a record is updated. This indicates support for versioning. I've set up a simple example (using OrientDB SQL) to test this:
create class Product
create property Product.name string
create property Product.price integer
insert into Product (name, price) values ('Fridge', 449)
update Product set price = 479 where name = 'Fridge'
select from Product
After executing the statements above, I get the following query result:
{
"result": [
{
"#type": "d",
"#rid": "#14:0",
"#version": 2,
"#class": "Product",
"name": "Fridge",
"price": 479
}
],
"notification": "Query executed in 0.031 sec. Returned 1 record(s)"
}
In this database state - how can I retrieve a previous version (version 1 in this simple case) of my record? Is this possible through an OrientDB SQL statement and/or via the OrientDB Java API? If not - what's the purpose of the #version property then?
The purpose of the #version property is to check if any update have been made between the time you fetched the object and when you updated it.
For instance if in your code you fetch a product, you update its properties, in the meanwhile the object has changed in the database (another piece of code has updated it), then you save it : you are trying to update the object with the version 2, but it has the version 3 in database.
This can help you to prevent concurrent access to your database.
I don't know if the functionality you are looking for will be implemented in OrientDB.
If you don't need it, then don't do it. If you really need this, you can do it yourself, maybe by creating a Product_old class and fill it with previous records on update.
My question is two parts:
First, when trying to create a unique node using the REST Interface like below...
http://localhost:7474/db/data/index/node/people?uniqueness=create_or_fail
What is the meaning of the "person" portion of the URL. I'm under the impression that it is a label but I'm not sure.
Second, if it is indeed a label, when I execute the following REST call...
http://localhost:7474/db/data/index/node/Test?uniqueness=create_or_fail
with this payload...
{
key: "name",
value: "test",
properties:
{
"lastName": "test",
"name": "test",
"type": "test",
"firstName": "test"
}
}
A node is created but does not have an associated label. It creates a label-less node that does still enforce uniqueness. How do I create a unique node using the REST API with a label?
I'm using neo4j 2.0.
You are correct. When you send in JSON, it will create the node, or fail if it already exists using the index label 'people'
When sending, you need to have in your object a "key" and "value" which denotes how to do the index matching.
How are you determining that the node has no label? In the REST documentation, I can see that the labels is a different URL call for a node, have you checked there?