We are trying to remove "doc" field which gets added on top of original document by Couchbase while doing XDCR.
For example:
Below is our sample original document :-
{
"UserID": "User1",
"FirstName": "First",
"LastName": "Last",
"Roles":
[
{
"RoleID" : "1",
"RoleName": "R_1"
}
]
}
But when we do XDCR from Couchbase to ElasticSearch, Couchbase adds "doc" field which holds the original document. Below is the sample document created by Couchbase XDCR :-
{
"doc":
{
"UserID": "User1",
"FirstName": "First",
"LastName": "Last",
"Roles":
[
{
"RoleID" : "1",
"RoleName": "R_1"
}
]
}
}
Is there a way to remove this "doc" field?
Thanks,
Sameer
Not in the current implementation - it's hardcoded. You can open a feature request to make it configurable, so it will be added in the next release.
Related
I have a REST Web Services Call that is returning data in the following format:
{
"Id": "0497cee4-45dc-47d8-97a8-b45ad8018775",
"Status": "OK",
"ProviderName": "MyApp",
"DateTimeUTC": "/Date(1508348383277)/",
"Contacts": [
{
"ContactID": "1efa0ea1-de5c-4172-869c-816e27c3c825",
"ContactStatus": "ACTIVE",
"Name": "Company",
"FirstName": "Joe",
"LastName": "Bob",
"EmailAddress": "mainguy#here.com",
"BankAccountDetails": "",
"ContactPersons": [
{
"FirstName": "Operations",
"LastName": "",
"EmailAddress": "there#here.com",
"IncludeInEmails": true
},
{
"FirstName": "Another",
"LastName": "Contact Email",
"EmailAddress": "here#there.com",
"IncludeInEmails": true
}
],
"HasAttachments": false,
}
]
}
Within Microsoft Flow I would like to grab the main contact email (Contacts.EmailAddress) as well as all of the secondary Contacts Emails (Contacts.ContactPersons[x].EmailAddress); and use that for the too field of down-flow email.
ContactPersons will not always be defined in every case, but Contacts.EmailAddress should be.
What is the best way to do this with a flow? Is there a way to concatenate data over a loop or something? I can't seem to find a way to do it.
Try using Data Operations (https://learn.microsoft.com/en-us/flow/data-operations).
You can start off with a Select, picking the EmailAddress field in the Map, and then redirecting that to a Join and using that output.
I am using Cygnus with Mongo and sth sink to retrieve historical data.
In the current implementation of cygnus mongo sink the attribute metadata is not stored in the data base. So I updated cygnus to be able to store the attribute metadata.
But when I use the STH-comet to retrieve the history, the API appreantly does not support retrieveing the attribute metadata.
Am I missing some kind of configuration or the API is not supporting the attribute metadata since the response that I am getting from STH-comet is:
{
"contextResponses": [
{
"contextElement": {
"attributes": [
{
"name": "humidity",
"values": [
{
"recvTime": "2017-03-08T08:06:11.463Z",
"attrType": "Number",
"attrValue": "999"
},
{
"recvTime": "2017-03-08T08:10:54.199Z",
"attrType": "Number",
"attrValue": "3.06"
}
]
}
],
"id": "Room1",
"isPattern": false,
"type": "Room"
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
In the mongoDB data base I have this content:
{ "_id" : ObjectId("58bfbb7c973c5c22d258cffc"), "recvTime" : ISODate("2017-03-08T08:06:11.463Z"), "attrName" : "humidity", "attrType" : "Number", "attrValue" : "999", "attrMetadata" : [ ] }
{ "_id" : ObjectId("58bfbc93973c5c22d258cffd"), "recvTime" : ISODate("2017-03-08T08:10:54.199Z"), "attrName" : "humidity", "attrType" : "Number", "attrValue" : "3.06", "attrMetadata" : [ { "name" : "unit", "type" : "Text", "value" : "voltage" } ] }
In case the API is not supporting the retrieval of the attribute metadata, can this feature be added?
Thanks & Best regards.
STH and Cygnus are aligned with regards to the information stored in MongoDB, both raw and aggregated one. In this sense, because Cygnus originally did not support for attribute metadata in NGSIMongoSink (the one in charge of storing the information in raw format), STH do not support attribute metadata in its raw API either.
As long as you have extended Cygnus functionality for this purpose, you'll have to extend STH API as well.
Question title pretty much self explanatory. It is possible to create an id-less entity in Orion. An id = .* query returns normally as an id-less, although existing entity. But how can someone delete that entity? This request didn't work obviously:
{
"contextElements": [
{
"type": "",
"isPattern": "false",
"id": ""
}
],
"updateAction": "DELETE"
}
This is the returned query:
{
"contextElement": {
"type": "",
"isPattern": "false",
"id": "",
"attributes": [
{
"name": "temp",
"type": "integer",
"value": "15"
},
{
"name": "pressure",
"type": "integer",
"value": "720"
}
]
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
There is a known bug (now fixed) in Orion that seems to be causing your issue. Basically Orion interprets the final "/" at the end of an URL as an empty element.
For example (as documented in the issue):
v1/contextEntityTypes queries for all types, while
v1/contextEntityTypes/ queries only for the empty type
In your particular case, something similar happens with some REST operations. If you do a GET /v1/contextEntities you will see all entities, including the empty-id one. You can query that particular entity with GET /v1/contextEntity/ (note the final "/").
And then, the DELETE method doesn't seem to use the same pattern. So if you do DELETE /v1/contextEntity/ You get a No context element found.
So, basically, this is another manifestation of a known bug.
How to update multiple documents in Solr 4.5.1 with JSON? I tried this but it does not work:
POST /solr/mycore/update/json:
{
"commit": {},
"add": {
"overwrite": true,
"doc": [{
"thumbnail": "/images/404.png",
"url": "/404.html?1",
"id": "demo:/404.html?1",
"channel": "demo",
"display_name": "One entry",
"description": "One entry is not enough."
}, {
"thumbnail": "/images/404.png",
"url": "/404.html?2",
"id": "demo:/404.html?2",
"channel": "demo",
"display_name": "Another entry",
"description": "Another entry is required."
}
]
}
}
Solr expects one "add"-key in the JSON-structure for each document (which might seem weird, if you think about the original meaning of the key in the object), since it maps directly to the XML format when doing the indexing - and this way you can have metadata for each document by itself.
{
"commit": {},
"add": {
"doc": {
"id": "321321",
"name": "barfoo"
}
},
"add": {
"doc": {
"id": "123123",
"name": "Foobar"
}
}
}
.. works. I think allowing an array as the element referenced by "add" would make more sense, but I haven't dug further into the source or know the reasoning behind this.
I understand that (at least) from versions 4.0 and older of solr, this has been fixed. Look at http://wiki.apache.org/solr/UpdateJSON.
In ./exampledocs/books.json there is an example of a json file with multiple documents.
[
{
"id" : "978-0641723445",
"cat" : ["book","hardcover"],
"name" : "The Lightning Thief",
"author" : "Rick Riordan",
"series_t" : "Percy Jackson and the Olympians",
"sequence_i" : 1,
"genre_s" : "fantasy",
"inStock" : true,
"price" : 12.50,
"pages_i" : 384
}
,
{
"id" : "978-1423103349",
"cat" : ["book","paperback"],
"name" : "The Sea of Monsters",
"author" : "Rick Riordan",
"series_t" : "Percy Jackson and the Olympians",
"sequence_i" : 2,
"genre_s" : "fantasy",
"inStock" : true,
"price" : 6.49,
"pages_i" : 304
},
...
]
While #fiskfisk answer is still a valid JSON, it is not easy to be serializable from a data structure. This one is.
elachell is correct that the array format will work if you are just adding documents with the default settings. Unfortunately, that won't work if, for instance, you need to add a custom boost to some of the documents or change the overwrite setting. You then have to use the full object structure with an "add" key for each of them, which as they pointed out, makes this frustratingly annoying to try to serialize from most languages which don't allow the same key more than once in an object:
{
"commit": {},
"add": {
"doc": {
"id": "321321",
"name": "barfoo"
},
"boost": 2.0
},
"add": {
"doc": {
"id": "123123",
"name": "Foobar"
},
"boost": 1.5,
"overwrite": false
}
}
Update for SOLR 8.8 (and maybe lower).
The following JSON works for /update/json:
{
'add': [
{'id': '123', 'field1': 'foo'},
{'id': '124', 'field1': 'foo'}
],
'delete': ['111', '106']
}
Another option if you are on Solr 4.10 or later is to use a custom JSON structure and tell Solr how to index it (not sure how to add boosts with this method either, but it's a nice option if you already have a data struct in JSON and don't want to convert it over to Solr's format). Here's the Solr documentation on this option:
https://cwiki.apache.org/confluence/display/solr/Uploading+Data+with+Index+Handlers#UploadingDatawithIndexHandlers-TransformingandIndexingCustomJSON
I am starting to implement a REST layer to an existing JSF-webapp (using RESTEasy, with a Jettison provider). Since tutorials for Java REST layers are quite basic (simple objects) I am facing the question how existing JPA entity relations can be easily exposed to/consumed from the client. A simple "/user" REST-method already gives me successfully the output below, which is a good start. But my main question is - how to deal with this kind of structures. Is it common to use such structures through REST?
I don't want to expose all details or the whole entity-tree, wether it is because of irrelevance, saving traffic or security issues. Using #XmlTransient works fine for the #Procudes, but merging these entities on a #POST/#PUT all #XmlTransient properties are merged to NULL. What is right way of doing that?
Since #XMLTransient is a global and permanent setting - what is the right approach to dynamically decide which depth of entity-tree I want to expose?
thanks
Example JSON of User-entity:
{
"user": {
"id": ..,
"uuid": "1521ccad69ba4579bbe49e75181fefc1",
"image": "",
"contact": {
"id": ..,
"uuid": "8eb429dcca994834ae5c8cf07cba62a2",
"cellphone": "",
"city": "",
"country": "",
"email": "mail#foo.bar",
"fax": "",
"phone": 555,
...
},
"name": "...",
"account": {
"id": ...,
"uuid": "80b331f9e6644449bb3600b0e5145253",
"confirmed": true,
"profile": {
"id": ...,
"uuid": "e172bdcafe2645d7975852ca5685c98c",
"locale": "en",
"notifyMessage": false,
"notifyNews": true,
"notifyTask": true,
"timeZone": "Europe/Berlin"
},
"roleProfiles": {
"id": ..,
"uuid": "f1713758f3f2416faed3e68350f2d759",
"active": true,
"assemblies": [
{
"id": ..,
"uuid": "13d72449833a4eb0b5b4f62c729ee44f",
"image": "",
"commercialRegisters": [
123,
456
],
"contact": {
"id": ...,
"uuid": "bef3802297344e3c8c3619b6c91c345a",
"city": "",
"country": "",
...
},
"thumbnail": ""
},
{
...
}
],
},
"userName": "..."
},
"displayName": "...",
"firstName": "Foo",
"lastName": "Bar",
"salutation": "",
"title": ""
}
}
Hi references in your Java classes should be serialized to JSON as links and not as values.
This is how Spring REST does it.
The good thing is : That way you have a kind of lazy loading
The bad thing is that the client needs additional requests to get the values of the references.
I developed a complete solution for that, but that was a hard piece of work.
The client (in javascript) creates proxies for those references and resolves them on demand.
I have a demo of that at demo.appdriver.com
In the upper right corner you see a link 'REST API' click it and you can see the REST API of a rather complex domain model.
Now you can start to click on the user interface , create, change, delete etc.
and have a look at the traffic between client and server.
Hope it helps !