I am trying to update value of some property in xDB using XQuery, here is my transaction:
let $source := doc('/historicalresource')/HistoricalResourceData[id/#UUID = '0361513e-30fa-45e4-a73a-d05870b8a284']
let $res := $source/ResourceProperty[#PropertyName="cpu|limit"]/#PropertyValue
let $change := '21572'
return replace value of node $res with $change
After running this query I receive such error:
com.xhive.error.XhiveException: VERSION_ACCESS_DENIED: This document
is versioned and can only be changed through a versioning operation
Indeed in my case historicalresource is a folder which may contain more than one document and all they have a version, like: v1.1 ,v1.2, etc..
How can I update the value of last version using xquery?
How should I modify my query to be able to update desired value ?
Finally, I have found the answer to my question, therefore adding it here:
There is no way to update xDB file using xQuery as it is version based system and xQuery cannot create a new version, but it could be done manually or automatically by some coding language (for example: java):
Manually - by editing existing version in xDB, in that case a new version will be automatically created after saving any change to existing version of the file.
Automatically - by checking out the file, making the change and submitting the change as a new version.
For versioned documents (on which XhiveLibraryChildIf.makeVersionable() was called), this is indeed the case: you have to check out the document first, then run the update query on the checked out copy, and finally check the new version in. For non-versioned documents, however, you can apply the update query directly.
Related
Started using the 'Preview App' late last week.
In the classic UI, we can highlight multiple rows and execute them all, like this for example...
update table.blah set updated_ts = current_timestamp()::timestamp_ntz, value = 1 where account_id = 5;
update table.blah set updated_ts = current_timestamp()::timestamp_ntz, value = 1 where account_id = 6;
In the new app.snowflake UI, we get the error...
000006 (0A000): Multiple SQL statements in a single API call are not supported; use one API call per statement instead.
This is a major annoyance. Is this something that is planned to be changed in a future release?
Thanks,
Craig
This is one of the current limitations of the new UI for Snowflake. Remember, it is only in Preview. You will see more and more functionality from the old interface be moved into the new interface over time. I am sure this is one of them.
The index.yaml file of my GAE app is no longer updated by the development server.
I have recently added a new kind to my app and a handler that queries this kind like so:
from google.appengine.ext import ndb
class MyKind(ndb.Model):
thing = ndb.TextProperty()
timestamp = ndb.DateTimeProperty(auto_now_add=True)
and in the handler I have a query
query = MyKind.query()
query.order(-MyKind.timestamp)
logging.info(query.iter().index_list())
entities = query.fetch(100)
for entity in entities:
# do something
AFAIK, the development server should create an index for this query and update index.yaml accordingly. However, it doesn't. It just looks like this:
indexes:
# AUTOGENERATED
The logging.info(query.iter().index_list()) should output the index used for the query, it just says 'None'. Also, the SDK console says 'Datastore contains no indexes.'
Running the query returns the entities unsorted. I have two questions:
is there some syntax error in my code causes the query results be unsorted or is it the missing index?
if it's the missing index, is there a way to manually force the dev server to update index.yaml? Other suggestions?
Thank you
your call to order returns the new query..
query = MyKind.query()
query = query.order(-MyKind.timestamp)
..to clarify..
query.order(-MyKind.timestamp) does not change the query, it returns a new one, so you need to use the query returned by that method. As it is query.order(-MyKind.timestamp) in your code does nothing.
when trying to access older versions of my managed XML files, it gives me something like:
DLS-INVALIDVERSION: (err:FOER0000) /company/1448220.xml has no version number 3
in /MarkLogic/dls.xqy, at 1403:6, ...
Indeed, the file of version 1, 2, 3 within /company/1448220_xml_versions does not exist (in this case lets assume version 4 is the most recent).
When updating a document using dls (Document Management) functions, I run the following tasks:
Check whether the document is managed or not
When its not managed, set to manage using dls:document-manage($uri, fn:false()) inside of an eval statement
Update the document using dls:document-checkout-update-checkin($uri, $new-doc, "Document
update", fn:true()) inside of an eval statement
So far so good.
When tying to get a specific version of a document:
dls:document-version($document-uri, xs:unsignedInt($version))
==> When using $version := 4 it gives me a valid document (which in turn is the most recent version)
==> When using $version := 1 it just gives me an error, indicating that the document of version 1 doesn't exist.
What I am doing wrong?
I am using MarkLogic 6.
You probably haven't set a retention policy using dls:retention-rule-insert, and the default retention rules retain nothing (which means that MarkLogic deletes all older versions of a given document each time you store a new version of it). See the "Defining a retention policy" section in the MarkLogic Application Developer's Guide, here.
I'm working with Solr indexing data from two sources - real-time "pump" inserting (and updating) documents into Solr and database which holds backups of those documents.
The problem we encountered looks like that - if we make a data import from database while pump is performing inserts, we may index a doc from pump, and later overwrite it with doc extracted from database - which is a backup, so it's probably little outdated.
If we close the pump, import from database and open the pump again, it probably will cause instabilities in our application.
What I'd like to do is tell Solr to not automatically overwrite the document, but do so conditionally (for example by the value of 'last_modified_date' field).
My question is - how can I do it? Do I have to modify Solr source, make a new class overwriting some update processor, or just add some magic lines to solrconfig?
Sorry, but there there is not an option or config to tell Solr to not automatically update documents, but instead use some conditional check. The current model for Solr is that if you insert a document with the same unique id as one already in the index, it will "update" that document by a delete/add operation. Solr also does not currently support the ability to only update specific fields in an existing indexed document. Please see issue SOLR-139 for more details.
Based on the scenario you have described, I would suggest that you create a process outside of Solr that handles the retrieval of items from your data sources and then performs the conditional check to see what is in the index already and determine if an update to the index is necessary.
You can use solr script processors to check if that document exists proceeds in its accordance
Below code only works when solr uses java 8
function processAdd(cmd) {
doc = cmd.solrDoc;
var previousDoc=null;
try {
// create a term type object
var Term = Java.type("org.apache.lucene.index.Term");
var TermObject =new Term("fieldForSearchTryUnique","Value of field");
//retrieve document id from solr return -1 if not present
previousDocId= req.getSearcher().getFirstMatch(TermObject);
if(-1!=perviousDocId) {
// get complete document from solr for that searched field
previousDoc=req.getSearcher().doc(previousDocId);
// do required process here
}
}
catch(err) {
logger.error("error in update processor "+err)
}
}
I am trying a case where we changed a field name in our entity. we have something like this for example
class Person {
String name; //The original declaration was "String fullName"
}
According to objectify you have to use annonation #AutoLoad(""). This is ok and it works as Google Datastore doesn't delete the data Actually but it makes a new field so this annotation is like a mapping between the old and the new field. No problem when you are reading the whole table.
The problem arises when you apply a filter on your query (Suppose you made 5 objects with old name and 5 with new name). The result of your query depends on whether you used the old variable name or the new one (returns back only 5 but never the 10). It won't fetch both of them and map them. Any Suggestions for this problem? I hope i explained it in a clear way.
Thanks in advance
The simplest straight forward solution. fetch all data with the annonation "AutoLoad()". Then store them again. In this way they will be saved as the new field. The old one doesn't exist anymore or at least it doesn't contain any data anymore. It is like migrating the data from the old name to the new name. Anyone has better suggestions ?
If you've changed the name of your field, you need to load and re-put all your data (using the mapreduce API would be one option here). There's no magic way around this - the data you've stored exists with two different names on disk.
You can use #OldName
http://www.mail-archive.com/google-appengine-java#googlegroups.com/msg05586.html