I got a strange issue regarding Domino fulltext-indexing:
When I save a document, and update the index (updall or via database properties) the index seems to still contain the old values.
So, if I update the field, lets say, 'Assignee' from value 'x' to value'y' and then update the index I can still find the document via FTSearch "[Assignee] = x", but not with "[Assignee] = y".
But the document has already the value "y" in it.
The index is only correct again, when I recreate it completely.
I'm using Domino 9.0.1
Is that some permission problem, or why would this happen?
Related
I am trying to search a way to add new categories in the present categories for my article using the select2 but as we know it only returns those which are already saved in the database.I want to do something so that those categories which are not there could get created automatically during the Runtime As figure shows no result found is displayed rather a new category should be created. Can anyone suggest a way to do it?
After purging a set of documents in a Couch database, some view results contain documents which are actually not there in the database. When accessing such documents following error message is returned
{"error":"not_found","reason":"missing"}
Also the view results contain duplicate entries for some of such "missing" documents.
Some of these docs contain conflicted revisions as well.
Following is a simple view which lists such documents. According to the view, there should not be duplicate results.
function(doc) {
if (doc.documentType == 'theDocType') {
emit(theDocType, doc);
}
}
I created a new document with an id of a "missing" document, and tried purging it again (giving the new rev and all the conflicting revs). But after purging, the view results remained same as earlier.
Any idea what has caused this and how to resolve this problem ?
I just recently had this issue too and found your question.
I fixed it by deleting the view records, stored here on Windows
"...\couchdb.2.1.1\data\.dbname_design\mrview\*.view"
here on Linux
<couch data directory>/.dbname_design\mrview*.view (usually /var/lib/couchdb or /usr/local/var/lib/couchdb)
Each .view is named with an md5, delete them all, then restart the service. Then request the view again and it will rebuild this index, it might take 2 or 3 attempts before it builds it properly depending on the size of the database.
Hopefully someone can add what the linux path is.
In a Sharepoint document library, I've some documents with version history. In C#, can I get the version history of a document and update the user?
The version history of the document is something line this:
Data Modified By
---- -----------
doc1 changed User X
some text User X
Using C#, can I update the Modified By user value with another user?
I'm guessing right now, but I think it should be possible to modify this value with object model without any problem. Just set it in your code with value you like ([UserId];#[SERVER\LoginName]) and instead of using Update method, use `SystemUpdate'. I'm quite sure that it works for Lists, didn't test it on Document Libraries.
Assuming you have the list item in oListItem, you need to set the Editor of the ListItem field by using FieldUserValue object:
FieldUserValue fldUser = new FieldUserValue();
fldUser.LookupId = User.Id;
clientContext.Load(fldUser);
clientContext.ExecuteQuery();//or use another way to get your user
oListItem["Editor"] = fldUser;
I have a CouchDB database in production. One of the documents has been edited (in Futon by an other developer).
And it's lost it's ID (don't ask me how he did it).
So now the document's id is an empty string, which makes it impossible to edit or delete via Futon.
Is there a way I could hack into CouchDB to delete that document anyway ?
I couldn't delete the document. But the database itself could be deleted.
And I couldn't reproduce the bug in locale. The other developer says he just removed the _id param and saved. I don't know what happened in CouchDB when he did it. But when I do so, it only recreates a new document (as we'd expect it to do).
So I've been using couch_docs to retrieve the datas locally.
As the id is empty, couch_docs doesn't imports it. So you don't even need to delete it manually.
Then I reimport all the records in an other database. I change the references to the database name in my config and everything works fine.
Destroying the database is not a problem even though there's an empty id.
Technically, a document ID is immutable so actually changing the _id field is not directly possible. Perhaps another document was created as a copy of the first?
A bug in CouchDB 1.1.0 allowed update functions to create empty string IDs.
A similar question asks about this and I gave a walkthrough of deleting empty ids there.
I haven't tried it but LoveSeat is supposed to be able to open and edit couchedb files...
This can be caused (and fixed!) by some error checking CouchDB was missing for _update handlers, as explained in How do you delete a couchdb document with an empty "" document id?
first of all I'm totally new to FAST but I already have a couple of issues I need to solve, so I'm sorry if my questions are very basic =)
Well, the problem is that I have a field in the FAST index which in the source document is something like "ABC 12345" (please note the intentional whitespaces) but when stored in the index is in the form "ABC 123456" (please note that now there is a single space).
If I retrieve all the document values then this specific value is OK (with all the whitespaces), my only problem is with the way the value is stored in the index since I need to retrieve and display it to my user just like it appears in the original document, and I don't want to go to the full document just for this value, I want the value that I already have in the index. I think I need to update one of the FAST XML configuration files but I don't have enough documentation at hand in order to decide where to perform the change, index_profile.xml? in the XMLMapper file?
I've found the answer by myself. I'm using a XMLMapper for my collection, all I had to do was to add the ignore-whitespace attribute to the Mapping element and then set this attribute value to "false". This solved the problem and the raw data now when retrieved from the index contains the expected inner whitespaces.
Thanks.