Is there any way to retrieve older version of same document in elasticsearch?
Suppose I've indexed 1 document in ES:
put class/student/1
{
"marks":95
}
Later point of time I want to update it to:
put class/student/1
{
"marks":96
}
As soon as I index the updated marks, I see '_version' getting updated as 2.
Is there any way to query ES and get _version=1 document?
This is not possible. Even though there is a version number associated with each create/index/update/delete operation, this version number can't be used to retrieve the older version of the document. Rather it can be used to prevent dirty reads while read/manipulate/index operations
Related
I'm not very used to Active Reports and I got an old software using those. The software provide some kind of stripped version of Active Reports Designer 7.
I got a PageFooter section with some fields and I want to remove one to display it only when it's the last page.
Basically, what I want to do is this in scripts :
if (this.PageNumber == this.PageCount) {
Field.Visible = true;
}
I only find one post here that say this.PageNumber should work, but it dosent.
So I tried to use the ReportInfo using the FormatString as {PageNumber}, but I don't seems to be able to read the value using this.ReportInfo.Value or this.ReportInfo.Text
I also tried to make a TextBox, using SummaryType : PageCount. But I'm still unable to read the Value.
So the question is :
How can I know the Page Number and Page Count in the script section?
Or how can I read the value of those textbox I created ?
Thanks a lot!
I think these docs cover what you are looking for:
https://help.grapecity.com/activereports/webhelp/Legacy/AR7Help/OnlineEN/AddPageNumbering.html
https://help.grapecity.com/activereports/webhelp/Legacy/AR7Help/OnlineEN/index.html
1.SOLR 7 extract pdf
will add many schema column(pdf meta)
and extra meta pdf data
2.in solr 6,it don't happen
4.how can i close it
My guess is that you're running with a "schemaless" update processor in 7, so that any unknown fields are added to the schema by the update processor. If you turn that off and use an explicit schema like you probably did in 6, you should see the old behavior again.
You might need to switch to the ClassicIndexSchemaFactory to get Solr to read your old schema.xml.
Rename the managed-schema file to schema.xml.
Modify solrconfig.xml to replace the schemaFactory class.
Remove any ManagedIndexSchemaFactory definition if it exists.
Add a ClassicIndexSchemaFactory definition as shown above
Reload the core(s).
I'm trying to select an entity with "The" as the first word of the title attribute but Usergrid seems to be ignoring it.
For example, this query which is attempting to select "The Giver"
/books?ql=select * where title contains 'the*' //returns no results
/books?ql=select * where title contains 'giver*' //returns "The Giver"
Is this be design? Why is "the" ignored? Is it some kind of keyword? How could I work around this apparent limitation?
This does not work in version 1.0 of Usergrid (the free tier of Apigee's API BaaS runs 1.0). It is, however, fixed in newer 2.X versions of the Usergrid project. I spent some time digging through for the relevant commit, but couldn't find it.
I've used Joel Krooswyk's Print All Backlog Story Cards solution for printing all stories in a backlog.
What I'd like to do is to extend this to have each card print the name of the parent feature that the card belongs to so I can print them all up and lay them on a table for a collaborative estimation session.
The issue is, I'm having trouble finding how to do it.
A snippet of his code in question:
queryArray[0] = {
key: CARD_TYPE,
type: 'hierarchicalrequirement',
query: '((Iteration.Name = "") AND (Release.Name = ""))',
fetch: 'Name,Iteration,Owner,FormattedID,PlanEstimate,ObjectID,Description,UserName',
order: 'Rank'
};
I can't seem to find the element to fetch!
Parent was listed on an example queries page(intended for use in the browser query functionality), with Parent.Name containing the actual text but so that hasn't worked - trying to find a reference that is clear about it seems to be eluding me.
I've looked at the type definition located at:
https://rally1.rallydev.com/slm/webservice/v2.0/typedefinition/?fetch=ObjectID&pagesize=100&pretty=true
Going to the hierarchical requirement's type definition from that page indicates it has a Parent field in one form or another.
I'm not even sure that that one will solve what I'm looking at.
A bit stuck, and I'm not sure what I'm trying to do is even possible with the hierarchical requirement object type.
Note: I assume even if I do find it I'll need to add some code to deal parentless stories- not worried about that though, that's easy enough to deal with once I find the actual value.
Many thanks to anyone who can help :)
I modified Joel's app to include PI/Feature's FormattedID to the cards when a story has a parent PI/Feature.
You may see the code in this github repo.
Parent field of a user story references another user story.
If you want to read a parent portfolio item of a user story, which is a Feature object, use Feature attribute or PortfolioItem attribute. Both will work:
if (data[i].PortfolioItem) {
//feature = data[i].PortfolioItem.FormattedID; //also works
//feature = data[i].Feature.Name; //also works
feature = data[i].Feature.FormattedID;
} else {
feature = "";
}
as long as the version of API is set in the code to 1.37 or above (up to 1.43).
PrintStoryCards app is AppSDK1 app.
1.33 is the latest version of AppSDK1.x
1.29, which the app is using is not aware of PortfoilioItems.
PortfolioItem was introduced in Rally in WS API version 1.37.
See API versioning section in the WS API documentation .
If you want to access Portfolio Items, or other features introduced in later versions of WS API up to 1.43 this syntax will allow it.
<script type="text/javascript" src="/apps/1.33/sdk.js?apiVersion=1.43"></script>
This has to be used with caution. One thing that definitely will break is around calculations of timebox start and end dates. That's why many legacy Rally App Catalog apps are still at 1.29.
This is due to changes in API Version 1.30.
Note that this method of setting a more advanced version of WS API for AppSDK1 does not work with v2.0 of WS API.
You should be able to add PortfolioItem to your fetch. Parent is the field used if the parent is a story. PortfolioItem is the field used if the parent is a Feature (or whatever your lowest level PI is).
Then in the results you can just get it like this:
var featureName = (story.PortfolioItem && story.PortfolioItem.Name) || 'None';
In attemp to find a bug in our project, I found myself with few questions about Lucene's indexing API with no answer:
The first one is related to the following snippet:
IndexWriter writer = //open an index for writings.
// ... do some heavy updates (inserts and deletes) to the index using 'writer'
IndexReader reader = writer.GetReader();
long[] idsArray = Field_Cache_Fields.DEFAULT.GetLongs(reader, "ID_Field");
//under the assumption that ALL indexed documents contain field with the name "ID_Field".
Is it promised by Lucene's API that the reader that I get will ALWAYS get the updated, even though uncommited index? Just to make sure my answer is clear: every deleted doc WONT be seen by the reader and every added doc WILL be..
The second question is related to the next snippet:
IndexWriter writer = //open an index for writing, but dont change a thing - just commit meta data.
writer.Commit["Hello"] = "World";
writer.Commit();
Is it promised that the metadata will be commited to the index, eventhough I opened it with no actual change to the index?
In both of the question I will be happy to know what was meant by the API, and also if some one knows about issues (any bugs?) specific with Lucene .Net 2.9.2
thanks guys!
First Question: yes
From the doc:
Expert: returns a readonly reader, covering all committed as well as un-committed changes to the index. This provides "near real-time" searching, in that changes made during an IndexWriter session can be quickly made available for searching without closing the writer nor calling #commit .
Note that this is functionally equivalent to calling {#commit} and then using IndexReader#open to open a new reader. But the turarnound time of this method should be faster since it avoids the potentially costly #commit .