I have been using DeleteByQueryRaw to successfully delete index objects but now I have updated to 0.12 it is missing. Is there a replacement 'raw' method of calling ES to delete in the new version?
Can you use the Delete By Query method that is part of 0.12, perhaps coupled with the DeleteByQueryParameters object to achieve the same results of using the previous DeleteByQueryRaw?
Update:
Appears that the forthcoming Elasticsearch.Net, which the next version of NEST will be built upon, will support/expose the entire ES API.
Elasticsearch.Net maps all the Elasticsearch API endpoints to methods.
See Elasticsearch.Net Building Requests for more details.
So based on this, you should be able to still do a 'raw' delete request using Elasticsearch.Net.
Related
Pretty simple you'd think given the popularity of both, but I am encountering a few hurdles.
I am using scaphold.io to be able to quickly show off a working UI. That is, if Vue can interact with Scaphold.
I have investigated two resources:
https://github.com/kristianmandrup/vue2-apollo-scaphold
Which seems to be a Scaphold production. Tried it. Many, many vague bugs.
Then there is also:
https://github.com/Akryum/vue-apollo
But this is too much. I don't need a server, the server is on Scaphold.
I also tried building the whole thing up by using the tutorial on howtographql, but this one is also outdated.
Ideally I want to instantiate an as up to date Vue 2 app using (I guess) the npm vue-cli, then install only the required apollo (or whatever, but I guess apollo) add-ons that I need. The minimum.
Shouldn't be too hard, I'll figure it out eventually, but some help is more than welcome.
You can consume a graphql api using your favorite regular request module (ajax, fetch, axios). Take the scalphold docs for example, but in the callback do this.vueUserData = body.data.getUser;
instead of
console.log(JSON.stringify(body, null, 2));
(edited to add one gotcha I remembered: if you encounter a problem where the callback doesn't know that this is supposed to be the component, you can do var self = this before the request function, then reference self.vueUserData instead.)
How to get from api information shown in the picture?
I have the connection to api, and I couldn't find in api documentation, the method to get this event details.
thank you.
You need the event.get method. See this page in the Zabbix manual: https://www.zabbix.com/documentation/3.0/manual/api/reference/event/get
Specifically, you probably need the second example, "Retrieving events by time period".
If you want to get trigger names, use the selectRelatedObject flag. As the default source is triggers, you should not get discovery, internal and auto-registration events.
If you really use the old 1.8 version, the flag for trigger names is select_triggers - see https://www.zabbix.com/documentation/1.8/api/event/get .
I was using Aerospike since 3.4 and Python client 1.0.31.
Currently upgraded to Aerospike 3.6.3 and Python client 1.0.50.
Since Python client doesn't have Async writes feature, I am planning to go with Golang. Also read that Go fits well with Aerospike (http://www.aerospike.com/blog/go-aerospike-a-perfect-match/)
I would like to know what are the consequence I will face on changing the client and how to handle them.
One of the issue I see is serialization. As I was using python client since Aerospike 3.4, How to handle older serialized data like float values. I Need not worry on new data as recent releases support floats natively.
Thanks in Advance.
Well, "Python client doesn't have Async" needs to come with a big yet. The C client 4.0.0 provides async operations. The current work being done in the Python client is compatibility with Python >= 3.4. Async is something that is planned.
The main thing to consider when moving from one language client to another, or when combining different SDKs is how to handle 'unsupported' types. You'll have to review your data for where it will contain serialized data in as_bytes, encoded as AS_BYTES_PYTHON. See the 'Serialization' section in the Python API doc. You want to come up with a common custom serialization scheme to allow your Go client to read that data.
I need a good example of using the LookbackAPI to get the data for a burn up chart. I see some limited questions and responses on the API but no examples on how I would use it to do so. I need to get the current scope on story points and story points completed.
Sorry for the scarcity of available examples. More and better examples will be coming as the LBAPI beta matures. I'd definitely recommend that you become familiar with the Lookback API (LBAPI) Documentation, as there are good examples there for formulating queries.
For a burnup, let's say you want to get the state Snapshots for an Iteration going from 15-Jan-2013 through 30-Jan-2013, and that the Iteration applies to a Project hierarchy that is four-deep. The following LBAPI query would obtain the PlanEstimate, ToDo, and Schedule State for Stories scheduled into that Iteration:
{
find:
{
_TypeHierarchy:"HierarchicalRequirement",
Children:null,
_ValidFrom:{
$gte:"2013-01-15TZ",
$lt:"2013-01-30TZ"
},
Iteration:{
$in:[
12345678910,
12345678911,
12345678912,
12345678913
]
}
},
fields:[
"PlanEstimate",
"ToDo",
"ScheduleState"
]
}
Where:
$in:[
12345678910,
12345678911,
12345678912,
12345678913
]
Are the ObjectID's of the Iteration called "Iteration 1". It's probably easiest to get these Object ID's from a standard WSAPI query on Iterations: (Name = "Iteration 1"). For Iterations copied into a four-deep project hierarchy, we would see the four Iteration OID's similar to the above.
For charting, the toughest part right now is an easy way to deal with the Time-Series data. The most robust way to query and process LBAPI data currently is by working directly against the REST endpoint and processing the returned JSON results in your own code.
With Javascript apps, for processing the data and turning it into a Chart, the preferred toolkit is AppSDK2, specifically the SnapshotStore.
For Javascript apps, the Lumenize javascript library is separate from LBAPI, but was developed by Rally's director of analytics and is bundled in the SDK. You can find some examples of using LBAPI and Lumenize to produce charting as part of some Rally-internal and Rally-customer Hackathon projects here:
https://github.com/RallyHackathon
Please be cautious with these examples for a couple of reasons:
Several aspects of the Lumenize namespace will be changing/renamed for clarity
There's a bug in the current version of Lumenize where its timeSeriesCalculator does not correctly account for stories deleted or reparented.
Hopefully there will be an updated version of AppSDK2 bundled and released soon to consolidate the Lumenize namespace and resolve the bug, so that there's better glue between AppSDK2 and LBAPI for Javascript App development.
Unfortunately, the .NET, Java and Python toolkits have not yet been updated to support the Lookback API. As a result, you'll have to do an HTTP POST to the Lookback API's REST endpoint directly, with a body similar to the one Mark W listed above and Content-Type 'application/json'.
I'd recommend using the Chrome extension 'XHR Poster' to experiment with what you're sending from a browser:
https://chrome.google.com/webstore/detail/xhr-poster/akdbimilobjkfhgamdhneckaifceicen
I have an object that I've faked with NSubstitute that has a method on it that gets called twice. I'd like to verify that the method has actually been called twice (and only twice). I've poked around the docs and Google with no luck. Any help would be appreciated. Thanks.
This currently isn't supported in NSubstitute 1.2.1 (the feature is implemented in a branch, and will make it to next release).
An alternative for now is to use substitute.ReceivedCalls() which will return an enumerable you can query. Another option is to use When..Do to increment a counter whenever the method is called, and assert that the counter ends up at 2.
Update 2011-11-19: This is supported in NSubstitute 1.3.0, using Received(int). It is documented on the Checking received calls page.