I have a doctrine array in column "tags" in table/entity "category".
FOS ElasticaBundle is up and working, and now I want to add the "tags" column to the search.
I cannot find any resources on how to set this up. Here is what I've tried and would like to do.
search:
client: default
types:
category:
mappings:
displayName: ~
searchRef: ~
tags:
type: 'array'
persistence:
driver: orm
model: SC\ProviderBundle\Entity\Category
provider: ~
listener: ~
finder: ~
I have three other types that use mapping type "nested" than run fine. The array expected has no keys, so I don't know what to put down for properties.
I'm getting this error
[Elastica\Exception\ResponseException]
MapperParsingException[mapping [category]]; nested: MapperParsingException[No handler for type [array] declared on field [tags]];
How do I set my mapping type "tags" as an array in Symfony2 using FOSElasticaBundle and where is this in any documentation?
The answer is
type:
category:
mappings:
tags:
type: 'string'
as described here
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-array-type.html
( working link, but idk if it's same page, someone feel free to edit and improve this answer )
https://www.elastic.co/guide/en/elasticsearch/reference/1.4/mapping-array-type.html
Came across the same question myself.
For the newest version of elasticsearch (v4) the type needs to be 'text':
type:
category:
mappings:
tags:
type: 'text'
Related
Conside this OpenAPI schema:
Units:
type: array
properties:
empty:
type: boolean
items:
$ref: '#/components/schemas/Unit'
Swagger Editor renders it as follows:
How should I interpret the 'empty' property ? Why is it seen as an ordered map?
Normally an array has items but no direct properties in it.
In this schema, the properties section is effectively ignored. The properties section has effect only for type: object and in typeless schemas, but it's not used with arrays. So this definition is equivalent to:
Units:
type: array
items:
$ref: '#/components/schemas/Unit'
The "OrderedMap" text in Swagger Editor's model renderer can be considered a display bug. Feel free to open an issue for this here: https://github.com/swagger-api/swagger-ui/issues
My first Drupal headless project with GraphQL and I am struggling with the logic behind the resolvers.
There is a content type "project" with a field "field_project_description". The field can store multiple values.
This is part of my schema:
type Project {
id: Int!
project_title: String!
project_description: [ProjectDescription]
}
type ProjectDescription {
value: String
}
And this is how the one part of the corresponding resolver looks:
$registry->addFieldResolver('ProjectDescription', 'value',
$builder->produce('property_path')
->map('type', $builder->fromValue('entity:node'))
->map('value', $builder->fromParent())
->map('path', $builder->fromValue('field_project_project_desc.value'))
);
But as far as I understand there has to be another resolver like
$registry->addFieldResolver('Project', 'project_description',
And I can't figure out, what this resolver has to look like.
Okay, I solved the problem myself. The answer is very simple actually.
You don't need a second resolver. Just one resolver with an additional PHP function, which flattens the arrays to the strings is enough. This is what the code looks like now.
The schema:
type Project {
id: Int!
project_title: String!
project_description: [String]
}
And the resolver:
$registry->addFieldResolver('Project', 'project_description',
$builder->compose(
$builder->produce('property_path')
->map('type', $builder->fromValue('entity:node'))
->map('value', $builder->fromParent())
->map('path', $builder->fromValue('field_project_project_desc')),
$builder->callback(function ($entity) {
$list = [];
foreach($entity as $item){
array_push($list, $item['value']);
}
return $list;
})
)
);
I hope I can help someone else with this.
I have a solr index with nested fields in the form of
{ record: [
{ tag1: foo, tag2: bar }
]
}
The solr configuration cannot be changed, unfortunately.
In Blacklight, I want to display foo and bar separately under different fields, like so:
Tag1: foo
Tag2: bar
I was thinking I could just use config.add_index_field with a helper method to achieve this:
catalog_controller.rb
config.add_index_field 'record', label: 'Tag1', helper_method: :get_tag1
config.add_index_field 'record', label: 'Tag2', helper_method: :get_tag2
application_helper.rb
def get_tag1(options={})
options[:value][0]['tag1']
end
def get_tag2(options={})
options[:value][0]['tag2']
end
However, when doing so I get the error A index_field with the key record already exists.
Apparently, I can only add one index field per solr field at a time. How can I turn one such field into multiple fields in Blacklight?
Found the answer. I simply need to add the field variable to point to the same tag, that way I can change the original variable.
catalog_controller.rb
config.add_index_field 'record1', label: 'Tag1', field: 'record', helper_method: :get_tag1
config.add_index_field 'record2', label: 'Tag2', field: 'record', helper_method: :get_tag2
Hi I created a SimpleSchema for a Mongo collection which has a variable number of sub-documents called measurables. Unfortunately it's been a while since I've done this and I can't remember how to insert into this type of schema! Can someone help me out?
The schema is as follows:
const ExerciseTemplates = new Mongo.Collection('ExerciseTemplates');
const ExerciseTemplateSchema = new SimpleSchema({
name: {
type: String,
label: 'name',
},
description: {
type: String,
label: 'description',
},
createdAt: {
type: Date,
label: 'date',
},
measurables: {
type: Array,
minCount: 1,
},
'measurables.$': Object,
'measurables.$.name': String,
'measurables.$.unit': String,
});
ExerciseTemplates.attachSchema(ExerciseTemplateSchema);
The method is:
Meteor.methods({
addNewExerciseTemplate(name, description, measurables) {
ExerciseTemplates.insert({
name,
description,
createdAt: new Date(),
measurables,
});
},
});
The data sent by my form for measurables is an array of objects.
The SimpleSchema docs seem to be out of date. If I use the example they show with measurables: type: [Object] for an array of objects. I get an error that the the type can't be an array and I should set it to Array.
Any suggestions would be awesome!!
Many thanks in advance!
edit:
The measurable variable contains the following data:
[{name: weight, unit: kg}]
With the schema above I get no error at all, it is silent as if it was successful, but when I check the db via CLI I have no collections. Am I doing something really stupid? When I create a new meteor app, it creates a Mongo db for me I assume - I'm not forgetting to actually create a db or something dumb?
Turns out I was stupid. The schema I posted was correct and works exactly as intended. The problem was that I defined my schema and method in a file in my imports directory, outside both client and server directories. This methods file was imported into the file with the form that calls the method, and therefore available on the client, but not imported into the server.
I guess that the method was being called on the client as a stub so I saw the console.log firing, but the method was not being called on the server therefore not hitting the db.
Good lesson for me regarding the new recommended file structure. Always import server side code in server/main.js!!! :D
Thanks for your help, thought I was going to go mad!
We have a rest API that is written in Java (hosted in Wildfly). Our service is running in kubernetes (GKE). We want to leverage Cloud Endpoints to track usage and responsiveness of our API. The API is not new, we have been shipping software that interacts with it for years. It is also quite large (thousands of public methods). We have Swagger documentation for our API, and have no validation errors. When I try to deploy our Swagger using:
gcloud beta service-management deploy swagger.yaml
It is not successful. I get the following error repeated 237 times:
ERROR: unknown location: http: body field path 'body' must be a non-repeated message.
I have tracked it down to 237 methods that include a json array in a body parameter. In our API these are methods that either accept or return a list of objects.
Is there any way I can get this accepted by service-management deploy? Changing our API isn't an option, but we would really like to be able to use endpoints.
For example, this method signature:
#PUT
#Path ("/foobars/undelete")
#Consumes (MediaType.APPLICATION_JSON)
#Produces (MediaType.APPLICATION_JSON)
#ApiOperation (value = "Undelete foobars")
#ApiResponses (value =
{
#ApiResponse (
code = 200,
message = "foobars undeleted",
response = FooBar.class,
responseContainer = "List"
) , #ApiResponse (
code = 206,
message = "Not all foobars undeleted",
response = FooBar.class,
responseContainer = "List"
) , #ApiResponse (
code = 410,
message = "Not found"
) , #ApiResponse (
code = 500,
message = "Server Error"
)
})
public Response undeleteFooBars (#ApiParam (value = "FooBar ID List") List<UUID> entityIds)
generates this swagger snippet:
"/foobars/undelete":
put:
tags:
- foo
summary: Undelete FooBars
description: ''
operationId: undeleteFooBars
consumes:
- application/json
produces:
- application/json
parameters:
- in: body
name: body
description: FooBar ID List
required: false
schema:
type: array
items:
type: string
format: uuid
responses:
'200':
description: Foo Bars undeleted
schema:
type: array
items:
"$ref": "#/definitions/FooBar"
'206':
description: Not all FooBars undeleted
schema:
type: array
items:
"$ref": "#/definitions/FooBar"
'410':
description: Not found
'500':
description: Server Error
I have had the exact same problem with Endpoints, where it does not seem to think that passing an array of objects is valid as a body parameter. I worked around this by just using a generic object and a decent description. The description will not programatically fix anything, but using a generic object allows Endpoints to work and the description gives information to the consumer of the API for what is expected.
parameters:
- in: body
name: body
description: Array of FooBar objects
required: false
schema:
type: object
This seems like an oversight on the part of the Endpoints team IMHO as using an array of objects in the body fits fine within the OpenApi spec and works with tools like http://editor.swagger.io/
Edit: I should also add that it is generally bad practice to use just a raw array as a request body or response body as it can cause a contract breaking change if additional properties are desired in the future, like say a count or pagination information.
If this is an existing API and you are just documenting the existing contract, then this solution will work to get the job done, but if you are designing a new API, then a better definition would be:
parameters:
- in: body
name: body
description: All the FooBar objects
required: false
schema:
type: object
properties:
items:
type: array
items:
$ref: '#/definitions/FooBarResource'
Since this could later be extended to add additional properties like
parameters:
- in: body
name: body
description: All the FooBar objects
required: false
schema:
type: object
properties:
count:
type: integer
description: The total count of resources
callbackUrl:
type: string
description: The URL to trigger once creation is complete
items:
type: array
items:
$ref: '#/definitions/FooBarResource'
description: The resources to create
You can do better than a plain object. Yyou can specify an array as the the value of an object with a single key. This way you preserve your type information:
parameters:
- description: "Your items to add"
in: body
name: listings
required: true
schema:
type: object
properties:
payload:
type: array
maxItems: 1000
minItems: 1
$ref: "#/definitions/listing"
It's ugly but at least it documents whatever the model you are passing in should look like.