Let's say I have a document in CouchDB and two users access that document to edit that at the same time.
How can I handle that because if the document is updated the _rev number will be changed and the other user could not save his changes..
How to merge both updates users made over the same documents?
You either resolve this client side sending update again with fresh _rev or (better) write the update handler function. Update handler takes as the argument current (up to date) document and parameters delivered from the user who executes the update. As the result function should return new document or null. You can considered it as server-side update in place. This way you do not have to worry about the _ver field.
Related
i have 3 mongo dB collection depended on each other but when i create the documents in the collection I want to delete the created documents if any other depended collection throw the error in the process.
What will be the better way to manage this.
my use case:
i have one controller where when customer submit the survey where i check if that customer already exist then i will not create customer else will create that customer in customer collection and then go to the reward function where i create the reward for the customer and then send the reward mail to the customer's email. then check in survey collection if survey already exist i throw the error if not then success response.
so how to delete depended collection's record if any collection get error while inserting the document.
I am thinking to check if i got the error in next function then i will delete the latest record from the above collection but that does not seems the best way to do it.
please see https://www.mongodb.com/docs/manual/core/transactions/
When a transaction aborts, all data changes made in the transaction are discarded without ever becoming visible. For example, if any operation in the transaction fails, the transaction aborts and all data changes made in the transaction are discarded without ever becoming visible.
I have a user that today is not replicating the new documents that the others users are adding on my CoucDB database, in other words the user A does not see the docuemnts that the users B, C is adding every day.
I have seen the last document added from the user A to CouchDB and I have seen that the document has a new field
_conflicts: ["2-17d3fcec15fbe3b1eed3e7f8a14eae35"]}
I guess the conflict is in the second revision of the document, Is not it? I have 7 revision about the same document
my question is How I can resolve it? How I can remove this conflict?
CouchDB does not attempt to merge the conflicting revision.
Your application dictates how the merging should be done.
see http://docs.couchdb.org/en/2.0.0/replication/conflicts.html
but generaly speaking the suggested algorithm to fetch a document with conflict resolution:
Get document via GET docid?conflicts=true request;
For each member in the _conflicts array call GET docid?rev=xxx. If any errors occur at this stage, restart from step 1. (There could be a race where someone else has already resolved this conflict and deleted that rev)
Perform application-specific merging
Write _bulk_docs with an update to the first rev and deletes of the other revs.
alos see the version on ruby
I know how to get the last document created by couchDB :
http://<IP>:5984/<DBname>/_changes?descending=true&limit=1
But my question is how to get the doc ID of the first document?
You can exclude the descending=true parameter from the URL and use only http://<IP>:5984/<DBname>/_changes?limit=1. However, according to the docs:
Only the most recent change for a given document is guaranteed to be provided, for example if a document has had fields added, and then deleted, an API client checking for changes will not necessarily receive the intermediate state of added documents.
So if the first document has been modified, it won't appear as the first item in the changes feed.
A way to achieve this would be to add a date_created timestamp in the documents when they are created and use a view that emits this field so that the documents are sorted by creation time.
I have a field on one of my base page types which I need to update programmatically from an external data feed, so that it can be included in my Smart Search index.
The documents are versioned, but I want to update the published value of this field regardless of checkout state, and obviously avoid any sort of overwrite when documents are checked in.
The field will not appear on the editor form -- or ideally, would conditionally display for Global Admins.
It appears that using the API to update the document without doing a CheckOut fails silently. However if I do a Checkout/Update/CheckIn on a checkout-out page, the author will lose their work I assume?
Any way to handle this "versionless" field via the Kentico data model and API?
I don't think there is a way around updating checked out pages. You can update the page type table directly, but as you mentioned, it will be overwritten when they check in. You could update the version history I believe to make changes to the current data that is checked out, but again, I think that will be lost if the user cancels.
The only way I can think of to solve your issue is to create another table that maps the values you want to the page. Then you don't have to worry about the pages being checked out, you just need to grab the documentID or something. Since the value isn't displayed to the editor, you just have a field that does a lookup on this table.
The preferred and right way is using the API but as you stated, it causes problems if a user has something already checked out and working on it or it's in workflow and not published yet.
If the field you're updating is page type specific, there is one thing specifically I can think of and that's going directly to the database to the page type's database field and perform an update to that field.
Note: this is not recommended unless you know specifically what you're doing and have done full testing on it
The down side of going direct to the database is this will not update the current version since you're using check in/out and workflow. You will also need to update the checked out and current version which means you need to:
Go to the Document itself in the cms_documents table and get the document you are working with.
Then using the fields DocumentCheckedOutVersionHistoryID and DocumentPublishedVersionHistoryID' you can get the version history IDs of the document from theCMS_VersionHistory` table.
Then you can perform an update to the CMS_VersionHistory and your custom page type fields.
You will then need to look in the CMS_WorkflowHistory table and find out if that document is in workflow and in what step.
After you have that workflow history step, use the VersionHistoryID field to go back to the CMS_VersionHistory table and update that record with your data.
Again, not an elegant solution since you are using check in/out and workflow but after some trial and error and testing you should be able to figure it out.
UPDATE
You may also be able to add a custom table or some other linked database table which will allow you to create a global handler. The linked table would be where you perform your updates via API and other calls without versioning or workflow. Then when a user updates a specific page type you could do a check to see when the last time that linked table was updated and update the field(s) you need on update of that particular page (of course by node and document IDs).
Unfortunately you'll have to check it in and out with API. See examples here.
Also you might need to publish it in order to reflect changes on the live site.
I have a CRM 2011 workflow and it should fire on change of one field, I have selected my field in ‘Record fields change’, but everytime i save all the workflows relating to that entity get fired. I am not understanding why all the workflows are firing for all the field changes.
Please let me know if anybody has any ideas.
Without seeing any code I'd have to take a guess here, but 9 times out of 10 it's due to you submitting more fields than you actually need to in the SDK.
When using the CRM SDK, don't ever perform updates by performing a select, which returns back more fields than what you are planning to update. Any fields in the attribute collection of the Entity will be updated even if they haven't changed. Instead, instantiate a new entity locally, set the id and whatever attributes you want to update and update it.