upon building my Elasticsearch query using Nest, i want to be able to see the JSON version of what's being sent to Elasticsearch. is this possible? some sort of deserializer i suppose.
here's the info for my follow up question:
{
"_infer": {
"defaultIndex": "myindex"
},
"acknowledged": false,
"isValid": false,
"connectionStatus": {
"success": false,
"requestMethod": "POST",
"requestUrl": "http://localhost:9200/myindex",
"settings": {},
"request": "ew0KICAic2V0dGluZ3MiOiB7DQogICAgImluZGV4Ijogew0KICAgICAgImFuYWx5c2lzIjogew0KICAgICAgICAiYW5hbHl6ZXIiOiB7DQogICAgICAgICAgImZ1bGxUZXJtQ2FzZUluc2Vuc2l0aXZlIjogew0KICAgICAgICAgICAgInRva2VuaXplciI6ICJrZXl3b3JkIiwNCiAgICAgICAgICAgICJmaWx0ZXIiOiBbDQogICAgICAgICAgICAgICJzdGFuZGFyZCIsDQogICAgICAgICAgICAgICJsb3dlcmNhc2UiDQogICAgICAgICAgICBdLA0KICAgICAgICAgICAgInR5cGUiOiAiY3VzdG9tIg0KICAgICAgICAgIH0sDQogICAgICAgICAgImZ1bGxUZXJtIjogew0KICAgICAgICAgICAgInRva2VuaXplciI6ICJrZXl3b3JkIiwNCiAgICAgICAgICAgICJmaWx0ZXIiOiBbDQogICAgICAgICAgICAgICJzdGFuZGFyZCINCiAgICAgICAgICAgIF0sDQogICAgICAgICAgICAidHlwZSI6ICJjdXN0b20iDQogICAgICAgICAgfSwNCiAgICAgICAgICAiY2FzZUluc2Vuc2l0aXZlIjogew0KICAgICAgICAgICAgInRva2VuaXplciI6ICJsb3dlcmNhc2UiLA0KICAgICAgICAgICAgImZpbHRlciI6IFsNCiAgICAgICAgICAgICAgInN0YW5kYXJkIg0KICAgICAgICAgICAgXSwNCiAgICAgICAgICAgICJ0eXBlIjogImN1c3RvbSINCiAgICAgICAgICB9DQogICAgICAgIH0NCiAgICAgIH0NCiAgICB9DQogIH0sDQogICJtYXBwaW5ncyI6IHsNCiAgICAic2VhcmNoZGF0YSI6IHsNCiAgICAgICJwcm9wZXJ0aWVzIjogew0KICAgICAgICAidXBjIjogew0KICAgICAgICAgICJ0eXBlIjogInN0cmluZyINCiAgICAgICAgfSwNCiAgICAgICAgInByb2R1Y3RpZCI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJ0aXRsZSI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJzdG9yZSI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJtZWRpYWZvcm1hdCI6IHsNCiAgICAgICAgICAidHlwZSI6ICJtdWx0aV9maWVsZCIsDQogICAgICAgICAgImZpZWxkcyI6IHsNCiAgICAgICAgICAgICJtZWRpYWZvcm1hdCI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImFuYWx5emVyIjogImZ1bGxUZXJtQ2FzZUluc2Vuc2l0aXZlIg0KICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICJyYXciOiB7DQogICAgICAgICAgICAgICJ0eXBlIjogInN0cmluZyIsDQogICAgICAgICAgICAgICJpbmRleCI6ICJub3RfYW5hbHl6ZWQiDQogICAgICAgICAgICB9DQogICAgICAgICAgfQ0KICAgICAgICB9LA0KICAgICAgICAibGFiZWwiOiB7DQogICAgICAgICAgInR5cGUiOiAic3RyaW5nIg0KICAgICAgICB9LA0KICAgICAgICAidmVuZG9yIjogew0KICAgICAgICAgICJ0eXBlIjogInN0cmluZyINCiAgICAgICAgfSwNCiAgICAgICAgImF2YWlsYWJsZWRhdGUiOiB7DQogICAgICAgICAgInR5cGUiOiAiZGF0ZSINCiAgICAgICAgfSwNCiAgICAgICAgInJlbGVhc2VkYXRlIjogew0KICAgICAgICAgICJ0eXBlIjogImRhdGUiDQogICAgICAgIH0sDQogICAgICAgICJsYXN0cmV0dXJuZGF0ZSI6IHsNCiAgICAgICAgICAidHlwZSI6ICJkYXRlIg0KICAgICAgICB9LA0KICAgICAgICAibm9ucmV0dXJuYWJsZSI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJtcGFhIjogew0KICAgICAgICAgICJ0eXBlIjogInN0cmluZyINCiAgICAgICAgfSwNCiAgICAgICAgImVzcmIiOiB7DQogICAgICAgICAgInR5cGUiOiAibXVsdGlfZmllbGQiLA0KICAgICAgICAgICJmaWVsZHMiOiB7DQogICAgICAgICAgICAiZXNyYiI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImFuYWx5emVyIjogImZ1bGxUZXJtQ2FzZUluc2Vuc2l0aXZlIg0KICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICJyYXciOiB7DQogICAgICAgICAgICAgICJ0eXBlIjogInN0cmluZyIsDQogICAgICAgICAgICAgICJpbmRleCI6ICJub3RfYW5hbHl6ZWQiDQogICAgICAgICAgICB9DQogICAgICAgICAgfQ0KICAgICAgICB9LA0KICAgICAgICAiY3NucmZsYWciOiB7DQogICAgICAgICAgInR5cGUiOiAic3RyaW5nIg0KICAgICAgICB9LA0KICAgICAgICAiY292ZXIiOiB7DQogICAgICAgICAgInR5cGUiOiAic3RyaW5nIg0KICAgICAgICB9LA0KICAgICAgICAic2l6ZSI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJjb2xvciI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJzdHlsZSI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJxb2giOiB7DQogICAgICAgICAgInR5cGUiOiAiaW50ZWdlciINCiAgICAgICAgfSwNCiAgICAgICAgImFkdWx0Ijogew0KICAgICAgICAgICJ0eXBlIjogImludGVnZXIiDQogICAgICAgIH0sDQogICAgICAgICJzYWxlc3JhbmsiOiB7DQogICAgICAgICAgInR5cGUiOiAiaW50ZWdlciINCiAgICAgICAgfSwNCiAgICAgICAgImxpc3RwcmljZSI6IHsNCiAgICAgICAgICAidHlwZSI6ICJkb3VibGUiDQogICAgICAgIH0sDQogICAgICAgICJzZWxsaW5ncHJpY2UiOiB7DQogICAgICAgICAgInR5cGUiOiAiZG91YmxlIg0KICAgICAgICB9LA0KICAgICAgICAiY29zdHByaWNlIjogew0KICAgICAgICAgICJ0eXBlIjogImRvdWJsZSINCiAgICAgICAgfSwNCiAgICAgICAgInNwZWNpYWxvcmRlciI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJmbGFncyI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJzYWxlc2NhdGVnb3J5Ijogew0KICAgICAgICAgICJ0eXBlIjogInN0cmluZyINCiAgICAgICAgfSwNCiAgICAgICAgImFydGlzdHMiOiB7DQogICAgICAgICAgInR5cGUiOiAib2JqZWN0IiwNCiAgICAgICAgICAicHJvcGVydGllcyI6IHsNCiAgICAgICAgICAgICJuYW1lIjogew0KICAgICAgICAgICAgICAidHlwZSI6ICJzdHJpbmciLA0KICAgICAgICAgICAgICAiYW5hbHl6ZXIiOiAiZnVsbFRlcm0iLA0KICAgICAgICAgICAgICAiaW5kZXgiOiAibm90X2FuYWx5emVkIg0KICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICJpZCI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImFuYWx5emVyIjogImZ1bGxUZXJtIiwNCiAgICAgICAgICAgICAgImluZGV4IjogIm5vdF9hbmFseXplZCINCiAgICAgICAgICAgIH0NCiAgICAgICAgICB9DQogICAgICAgIH0sDQogICAgICAgICJkaXJlY3RvcnMiOiB7DQogICAgICAgICAgInR5cGUiOiAib2JqZWN0IiwNCiAgICAgICAgICAicHJvcGVydGllcyI6IHsNCiAgICAgICAgICAgICJuYW1lIjogew0KICAgICAgICAgICAgICAidHlwZSI6ICJzdHJpbmciLA0KICAgICAgICAgICAgICAiYW5hbHl6ZXIiOiAiZnVsbFRlcm0iLA0KICAgICAgICAgICAgICAiaW5kZXgiOiAibm90X2FuYWx5emVkIg0KICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICJpZCI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImFuYWx5emVyIjogImZ1bGxUZXJtIiwNCiAgICAgICAgICAgICAgImluZGV4IjogIm5vdF9hbmFseXplZCINCiAgICAgICAgICAgIH0NCiAgICAgICAgICB9DQogICAgICAgIH0sDQogICAgICAgICJzdGFycmluZyI6IHsNCiAgICAgICAgICAidHlwZSI6ICJvYmplY3QiLA0KICAgICAgICAgICJwcm9wZXJ0aWVzIjogew0KICAgICAgICAgICAgIm5hbWUiOiB7DQogICAgICAgICAgICAgICJ0eXBlIjogInN0cmluZyIsDQogICAgICAgICAgICAgICJhbmFseXplciI6ICJmdWxsVGVybSIsDQogICAgICAgICAgICAgICJpbmRleCI6ICJub3RfYW5hbHl6ZWQiDQogICAgICAgICAgICB9LA0KICAgICAgICAgICAgImlkIjogew0KICAgICAgICAgICAgICAidHlwZSI6ICJzdHJpbmciLA0KICAgICAgICAgICAgICAiYW5hbHl6ZXIiOiAiZnVsbFRlcm0iLA0KICAgICAgICAgICAgICAiaW5kZXgiOiAibm90X2FuYWx5emVkIg0KICAgICAgICAgICAgfQ0KICAgICAgICAgIH0NCiAgICAgICAgfSwNCiAgICAgICAgImNyZWRpdHMiOiB7DQogICAgICAgICAgInR5cGUiOiAib2JqZWN0IiwNCiAgICAgICAgICAicHJvcGVydGllcyI6IHsNCiAgICAgICAgICAgICJuYW1lIjogew0KICAgICAgICAgICAgICAidHlwZSI6ICJzdHJpbmciLA0KICAgICAgICAgICAgICAiYW5hbHl6ZXIiOiAiZnVsbFRlcm0iLA0KICAgICAgICAgICAgICAiaW5kZXgiOiAibm90X2FuYWx5emVkIg0KICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICJpZCI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImFuYWx5emVyIjogImZ1bGxUZXJtIiwNCiAgICAgICAgICAgICAgImluZGV4IjogIm5vdF9hbmFseXplZCINCiAgICAgICAgICAgIH0NCiAgICAgICAgICB9DQogICAgICAgIH0sDQogICAgICAgICJhZGRpdGlvbmFsdGl0bGVzIjogew0KICAgICAgICAgICJ0eXBlIjogInN0cmluZyIsDQogICAgICAgICAgImFuYWx5emVyIjogImNhc2VJbnNlbnNpdGl2ZSINCiAgICAgICAgfSwNCiAgICAgICAgImF0dHJpYnV0ZXMiOiB7DQogICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAiYW5hbHl6ZXIiOiAiY2FzZUluc2Vuc2l0aXZlIg0KICAgICAgICB9LA0KICAgICAgICAic3BlY2lhbHR5Ijogew0KICAgICAgICAgICJ0eXBlIjogIm11bHRpX2ZpZWxkIiwNCiAgICAgICAgICAiZmllbGRzIjogew0KICAgICAgICAgICAgInNwZWNpYWx0eSI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImFuYWx5emVyIjogImZ1bGxUZXJtQ2FzZUluc2Vuc2l0aXZlIg0KICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICJyYXciOiB7DQogICAgICAgICAgICAgICJ0eXBlIjogInN0cmluZyIsDQogICAgICAgICAgICAgICJpbmRleCI6ICJub3RfYW5hbHl6ZWQiDQogICAgICAgICAgICB9DQogICAgICAgICAgfQ0KICAgICAgICB9LA0KICAgICAgICAiZ2VucmVzIjogew0KICAgICAgICAgICJ0eXBlIjogIm11bHRpX2ZpZWxkIiwNCiAgICAgICAgICAiZmllbGRzIjogew0KICAgICAgICAgICAgImdlbnJlcyI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImFuYWx5emVyIjogImZ1bGxUZXJtQ2FzZUluc2Vuc2l0aXZlIg0KICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICJyYXciOiB7DQogICAgICAgICAgICAgICJ0eXBlIjogInN0cmluZyIsDQogICAgICAgICAgICAgICJpbmRleCI6ICJub3RfYW5hbHl6ZWQiDQogICAgICAgICAgICB9DQogICAgICAgICAgfQ0KICAgICAgICB9LA0KICAgICAgICAidGhlbWUiOiB7DQogICAgICAgICAgInR5cGUiOiAibXVsdGlfZmllbGQiLA0KICAgICAgICAgICJmaWVsZHMiOiB7DQogICAgICAgICAgICAidGhlbWUiOiB7DQogICAgICAgICAgICAgICJ0eXBlIjogInN0cmluZyIsDQogICAgICAgICAgICAgICJhbmFseXplciI6ICJmdWxsVGVybUNhc2VJbnNlbnNpdGl2ZSINCiAgICAgICAgICAgIH0sDQogICAgICAgICAgICAicmF3Ijogew0KICAgICAgICAgICAgICAidHlwZSI6ICJzdHJpbmciLA0KICAgICAgICAgICAgICAiaW5kZXgiOiAibm90X2FuYWx5emVkIg0KICAgICAgICAgICAgfQ0KICAgICAgICAgIH0NCiAgICAgICAgfSwNCiAgICAgICAgInByaWNlIjogew0KICAgICAgICAgICJ0eXBlIjogIm11bHRpX2ZpZWxkIiwNCiAgICAgICAgICAiZmllbGRzIjogew0KICAgICAgICAgICAgInByaWNlIjogew0KICAgICAgICAgICAgICAidHlwZSI6ICJzdHJpbmciLA0KICAgICAgICAgICAgICAiYW5hbHl6ZXIiOiAiZnVsbFRlcm1DYXNlSW5zZW5zaXRpdmUiDQogICAgICAgICAgICB9LA0KICAgICAgICAgICAgInJhdyI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImluZGV4IjogIm5vdF9hbmFseXplZCINCiAgICAgICAgICAgIH0NCiAgICAgICAgICB9DQogICAgICAgIH0sDQogICAgICAgICJ0cmFja3MiOiB7DQogICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAiYW5hbHl6ZXIiOiAiY2FzZUluc2Vuc2l0aXZlIg0KICAgICAgICB9LA0KICAgICAgICAiZGVsZXRlZCI6IHsNCiAgICAgICAgICAidHlwZSI6ICJzdHJpbmciDQogICAgICAgIH0sDQogICAgICAgICJ1cGRhdGVkYXRlIjogew0KICAgICAgICAgICJ0eXBlIjogImRhdGUiDQogICAgICAgIH0sDQogICAgICAgICJwcm9jZXNzZWQiOiB7DQogICAgICAgICAgInR5cGUiOiAic3RyaW5nIg0KICAgICAgICB9LA0KICAgICAgICAiZGVjYWRlcyI6IHsNCiAgICAgICAgICAidHlwZSI6ICJtdWx0aV9maWVsZCIsDQogICAgICAgICAgImZpZWxkcyI6IHsNCiAgICAgICAgICAgICJkZWNhZGVzIjogew0KICAgICAgICAgICAgICAidHlwZSI6ICJzdHJpbmciLA0KICAgICAgICAgICAgICAiYW5hbHl6ZXIiOiAiZnVsbFRlcm1DYXNlSW5zZW5zaXRpdmUiDQogICAgICAgICAgICB9LA0KICAgICAgICAgICAgInJhdyI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImluZGV4IjogIm5vdF9hbmFseXplZCINCiAgICAgICAgICAgIH0NCiAgICAgICAgICB9DQogICAgICAgIH0sDQogICAgICAgICJwZXJpb2QiOiB7DQogICAgICAgICAgInR5cGUiOiAibXVsdGlfZmllbGQiLA0KICAgICAgICAgICJmaWVsZHMiOiB7DQogICAgICAgICAgICAicGVyaW9kIjogew0KICAgICAgICAgICAgICAidHlwZSI6ICJzdHJpbmciLA0KICAgICAgICAgICAgICAiYW5hbHl6ZXIiOiAiZnVsbFRlcm1DYXNlSW5zZW5zaXRpdmUiDQogICAgICAgICAgICB9LA0KICAgICAgICAgICAgInJhdyI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImluZGV4IjogIm5vdF9hbmFseXplZCINCiAgICAgICAgICAgIH0NCiAgICAgICAgICB9DQogICAgICAgIH0sDQogICAgICAgICJwbGF0Zm9ybSI6IHsNCiAgICAgICAgICAidHlwZSI6ICJtdWx0aV9maWVsZCIsDQogICAgICAgICAgImZpZWxkcyI6IHsNCiAgICAgICAgICAgICJwbGF0Zm9ybSI6IHsNCiAgICAgICAgICAgICAgInR5cGUiOiAic3RyaW5nIiwNCiAgICAgICAgICAgICAgImFuYWx5emVyIjogImZ1bGxUZXJtQ2FzZUluc2Vuc2l0aXZlIg0KICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICJyYXciOiB7DQogICAgICAgICAgICAgICJ0eXBlIjogInN0cmluZyIsDQogICAgICAgICAgICAgICJpbmRleCI6ICJub3RfYW5hbHl6ZWQiDQogICAgICAgICAgICB9DQogICAgICAgICAgfQ0KICAgICAgICB9DQogICAgICB9DQogICAgfQ0KICB9DQp9",
"numberOfRetries": 0,
"httpStatusCode": 400,
"serializer": {},
"successOrKnownError": true
},
"infer": {
"defaultIndex": "myindex"
}
}
Yup. You can use the serializer that is exposed by ElasticClient like this:
var query = Nest.Query<SomeObject>...
var json = Client.Serializer.SerializeToString(query);
You can also use Newtonsoft directly, or any JSON library for that matter to serialize your query object. Using the serializer in ElasticClient though (which essentially wraps Newtonsoft), will give you the exact JSON that NEST will generate.
Checkout how the unit tests are done in NEST for more details, specifically this.
I used SearchDescriptor like this for a complex query:
SearchDescriptor<T> sd = new SearchDescriptor<T>()
.From(0).Size(100)
.Query(q => q
.Bool(t => t
.Must(u => u
.Bool(v => v
.Should(
...
)
)
)
)
);
And got the deserialized JSON like this:
{
"from": 0,
"size": 100,
"query": {
"bool": {
"must": [
{
"bool": {
"should": [
...
]
}
}
]
}
}
}
It was annoying, NEST library should have something that spits out the JSON from request. However this worked for me:
using (MemoryStream mStream = new MemoryStream()) {
client.Serializer.Serialize(sd, mStream);
Console.WriteLine(Encoding.ASCII.GetString(mStream.ToArray()));
}
NEST library version: 2.0.0.0.
Newer version may have an easier method to get this (Hopefully).
If the above answer doesn't work, or you want a simpler one, I posted another way here on what is probably a duplicate, (but differently worded) question:
https://stackoverflow.com/a/31247636/261405
Add this to your WebApiConfig.cs:
public static void Register(HttpConfiguration config)
{
...
// ignore circular reference globally
config.Formatters.JsonFormatter.SerializerSettings.ReferenceLoopHandling = Newtonsoft.Json.ReferenceLoopHandling.Ignore;
...
}
Then you should be able to do something like this:
// Return raw
var esObj = await _client.SearchAsync<object>(searchRequest);
// more specific deserialization using Newtonsoft.Json example
foreach (var hit in esObj.Hits)
{
var myObj = JsonConvert.DeserializeObject<MyObject>(hit.xxx);
...
}
For Nest 5.3.0 :
var memoryStream = new System.IO.MemoryStream();
client.Serializer.Serialize(query, memoryStream);
var jsonQuery = System.Text.Encoding.UTF8.GetString(memoryStream.ToArray());
Related
I could not find a way to translate the fowling MongoDb command into C#
db.Queue.aggregate(
[
{ $match: { "Processed": false } },
{ $sort: { "LastTimeChanged": 1 } },
{ $limit: 1 },
{ $set: { "WorkerName": "WORKER_NAME", "Processed": true } },
{ "$merge": "Queue" }])
The issues that I fund was with the $set and $merge command
$set -> in the MongoDb.Driver for .NET, associated with the Aggregate command I could not find any command that look like the $set
$merge -> the merge command examples are exclusive for merging collections and in this case, I could not find a way to use the Merge method in the API.
Any one can throw light here!??
thanks
Paulo Aboim Pinto
I found a way to execute the command using the MongoDb.Driver but I thing there should be a better and fluent way of doing it
var filter = Builders<QueueCollection>.Filter.And
(
Builders<QueueCollection>.Filter.Eq(x => x.WorkerName, string.Empty),
Builders<QueueCollection>.Filter.Eq(x => x.Processed, false)
);
var sortOptions = Builders<QueueCollection>
.Sort.Ascending("LastTimeChanged");
this.queueCollection.Aggregate()
.Match(filter)
.Sort(sortOptions)
.Limit(1)
.AppendStage<QueueCollection>("{ $set: { 'WorkerName': 'WORKER_NAME' } }")
.AppendStage<QueueCollection>("{ $merge: 'Queue' }")
.ToList();
This works for now, but I would like to want still to know:
How do I replace the $set in the Aggregate pipeline
How do I write a proper $merge command.
thanks in advance for any answer
Paulo Aboim Pinto
I am really struggling with this concept. I hope someone can help me understand it better.
The documentations uses a simple example and it's not 100% clear to me how it works.
I have tried using keyArgs, but they didn't work, so I adopted to use the args parameter in the read and merge functions. First, let me explain my scenario.
I have a couple of search endpoints that use the same parameters:
{
search:
{
searchTerm: "*",
includePartialMatch: true,
page: 1,
itemsToShow: 2,
filters: {},
facets: [],
orderBy: {}
}
}
So I have setup my type policies like this:
const cache = new InMemoryCache({
typePolicies: {
Query: {
fields: {
searchCategories: typePolicy,
searchBrands: typePolicy,
searchPages: typePolicy,
searchProducts: typePolicy,
},
},
},
});
And I was using a generic typePolicy for them all.
At first, I tried this:
const typePolicy = {
keyArgs: [
"search",
[
"identifier",
"searchTerm",
"includePartialMatches",
"filters",
"orderBy",
"facets",
],
],
// Concatenate the incoming list items with
// the existing list items.
merge(existing: any, incoming: any) {
console.log("existing", existing);
console.log("incoming", incoming);
if (!existing?.items) console.log("--------------");
if (!existing?.items) return { ...incoming }; // First request
const items = existing.items.concat(incoming.items);
const item = { ...existing, ...incoming };
item.items = items;
console.log("merged", item);
console.log("--------------");
return item;
},
};
But this does not do what I want.
What I would like, is for apollo to work as it does normally, but when the "page" changes for any field, it appends it instead of caching a new request.
Does anyone know what I am doing wrong or can provide me with a better example that what is on the documentation?
I've got a very simple Nuxt app with Strapi GraphQL backend that I'm trying to use and learn more about GraphQL in the process.
One of my last features is to implement a search feature where a user enters a search query, and Strapi/GraphQL performs that search based on attributes such as image name and tag names that are associated with that image. I've been reading the Strapi documentation and there's a segment about performing a search.
So in my schema.graphql, I've added this line:
type Query {
...other generated queries
searchImages(searchQuery: String): [Image
}
Then in the /api/image/config/schema.graphql.js file, I've added this:
module.exports = {
query: `
searchImages(searchQuery: String): [Image]
`,
resolver: {
Query: {
searchImages: {
resolverOf: 'Image.find',
async resolver(_, { searchQuery }) {
if (searchQuery) {
const params = {
name_contains: searchQuery,
// tags_contains: searchQuery,
// location_contains: searchQuery,
}
const searchResults = await strapi.services.image.search(params);
console.log('searchResults: ', searchResults);
return searchResults;
}
}
}
},
},
};
At this point I'm just trying to return results in the GraphQL playground, however when I run something simple in the Playground like:
query($searchQuery: String!) {
searchImages(searchQuery:$searchQuery) {
id
name
}
}
I get the error: "TypeError: Cannot read property 'split' of undefined".
Any ideas what might be going on here?
UPDATE:
For now, I'm using deep filtering instead of the search like so:
query($searchQuery: String) {
images(
where: {
tags: { title_contains: $searchQuery }
name_contains: $searchQuery
}
) {
id
name
slug
src {
url
formats
}
}
}
This is not ideal because it's not an OR/WHERE operator, meaning it's not searching by tag title or image name. It seems to only hit the first where. Ideally I would like to use Strapi's search service.
I actually ran into this problem not to recently and took a different solution.
the where condition can be combined with using either _and or _or. as seen below.
_or
articles(where: {
_or: [
{ content_contains: $dataContains },
{ description_contains: $dataContains }
]})
_and
(where: {
_and: [
{slug_contains: $categoriesContains}
]})
Additionally, these operators can be combined given that where in this instance is an object.
For your solution I would presume you want an or condition in your where filter predicate like below
images(where: {
_or: [
{ title_contains: $searchQuery },
{ name_contains: $searchQuery }
]})
Lastly, you can perform a query that filters by a predicate by creating an event schema and adding the #search directive as seen here
I am trying to create an Elasticsearch MLT query using NEST's object initializer syntax. However, the final query when serialized, is ONLY missing the MLT part of it. Every other query is present though.
When inspecting the query object, the MLT is present. It's just not getting serialized.
I wonder what I may be doing wrong.
I also noticed that when I add Fields it works. But I don't believe fields is a mandatory property here that when it is not set, then the MLT query is ignored.
The MLT query is initialized like this;
new MoreLikeThisQuery
{
Like = new[]
{
new Like(new MLTDocProvider
{
Id = parameters.Id
}),
}
}
MLTDocProvider implements the ILikeDocument interface.
I expect the serialized query to contain the MLT part, but it is the only part that is missing.
This looks like a bug in the conditionless behaviour of more like this query in NEST; I've opened an issue to address. In the meantime, you can get the desired behaviour by marking the MoreLikeThisQuery as verbatim, which will override NEST's conditionless behaviour
var client = new ElasticClient();
var parameters = new
{
Id = 1
};
var searchRequest = new SearchRequest<Document>
{
Query = new MoreLikeThisQuery
{
Like = new[]
{
new Like(new MLTDocProvider
{
Id = parameters.Id
}),
},
IsVerbatim = true
}
};
var searchResponse = client.Search<Document>(searchRequest);
which serializes as
{
"query": {
"more_like_this": {
"like": [
{
"_id": 1
}
]
}
}
}
I am trying to work Ember with Parse.com using
ember-model-parse-adapter by samharnack.
I add added a function to make multiple work search(like search engine) for which I have defined a function on cloud using Parse.Cloud.define and run from client.
The problem is the Array that my cloud response returns is not compatible with Ember Model because of two attributes they are __type and className. how can I modify the response to get response similar to that i get when I run a find query from client. i.e without __type and className
Example responses
for App.List.find() = {
"results":[
{
"text":"zzz",
"words":[
"zzz"
],
"createdAt":"2013-06-25T16:19:04.120Z",
"updatedAt":"2013-06-25T16:19:04.120Z",
"objectId":"L1X55krC8x"
}
]
}
for App.List.cloudFunction("sliptSearch",{"text" : this.get("searchText")})
{
"results":[
{
"text":"zzz",
"words":[
"zzz"
],
"createdAt":"2013-06-25T16:19:04.120Z",
"updatedAt":"2013-06-25T16:19:04.120Z",
"objectId":"L1X55krC8x",
"__type" : Object, //undesired
"className" : "Lists" //undesired
}
]
}
Thanks Vlad something like this worked for me for array
resultobj = [];
searchListQuery.find({
success: function(results) {
for( var i=0, l=results.length; i<l; i++ ) {
temp = results.pop();
resultobj.push({
text: temp.get("text"),
createdAt: temp.createdAt,
updatedAt: temp.updatedAt,
objectId: temp.id,
words: "",
hashtags: ""
});
}
In your cloud code before you make any response, create and object and extract from it the attributes/members you need and then response it. like so:
//lets say result is some Parse.User or any other Parse.Object
function(result)
{
var responseObj = {};
responseObj.name = responseObj.get("name");
responseObj.age = responseObj.get("age");
responseObj.id = responseObj.id;
response.success(responseObj);
}
on the response side you will get {"result": {"name": "jhon", "age": "26", "id": "zxc123s21"}}
Hope this would help you