Here is the the problem. Let's say, I have this rule:
{
pattern: ( [ner:/DATE|TIME/] ),
action: ( Annotate($0, myNER, "MY_DATETIME" ) )
}
Instead of annotating the capture group $0, how can I specify the entire document, sort of like this:
{
pattern: ( [ner:/DATE|TIME/] ),
action: ( Annotate( <document>, myNER, "MY_DATETIME" ) )
}
This can be a very useful feature that allows annotating the whole document (or perhaps a sentence) when a specific token pattern is found. Thanks.
At the moment there isn't an implemented way to do this. There isn't a direct way to get access to the CoreMap representing the document through TokensRegex.
What would be necessary is for every token to have a pointer to the document CoreMap, then you could access the overall document in the TokensRegex rules by looking at a specific token, but this would require making some changes to the code.
If you want to open a GitHub issue we could try to add this functionality in future versions.
Related
I am using Vuetify and use its default way of adding rules to input fields.
I know there is this rule:
v => !!v
This checks if the the form input isn't empty. But how can I make it in such a way that it only accepts alphabetical letters, numbers or even apply a regex to it? I can't find anything in the docs. Can someone with any experience help me out?
So I assume that you've probably sorted this now but for anyone finding this from google etc.
To add a new rule, you need to add it to your vue component, either through an import or just adding it straight to your data object. You name it as you would any other data property and it's an array of the tests like the v => !!v one you mentioned. You then add the OR operator followed by the text to show on a failed validation.
So to add a regex that only allows letters you would have this:
data () {
return {
alphaRule: [
v => /[a-zA-Z]+$/.test(v) || 'Field must only contain letters'
]
}
}
then on your form field you would have <v-text-field :rules="alphaRule"></v-text-field>
That said, I would highly recommend adding all of your rules to a Rules.js file and binding the rules globally so that you can access them anywhere, have a centralised repository for them, and it helps keeps your code DRY too.
I have just made a big ol list of rules inspired by Laravel's Validation rules and will edit my answer to include them oncce I have finished testing them.
EDIT
Here are all the rules I'm currently using in production. Hopefully they'll help someone else! You'll need to import them into your component to use them, or you can globally include them through a vue mixin.
I'm using react-apollo#2.5.6
I have a component, when you click on it, it will based on "select" state and issue either an add or a remove operation.
Currently I'm doing this to have 2 mutations function injected to my component. Is that the correct way to do it? Am I able to just use one Mutation ( HOC ) instead of multiple ?
<Mutation mutation={ADD_STUFF}>
{(addStuff) => (
<Mutation mutation={REMOVE_STUFF}>
{(removeStuff) => {
And later in the wrapped component, I will do something like that
onClick={(e) => {
e.preventDefault()
const input = {
variables: {
userId: user.id,
stuffId: stuff.id,
},
}
// Based on selected state, I will call either add or remove
if (isSelected) {
removeStuff(input)
} else {
addStuff(input)
}
}}
Thanks
Everything is possible but usually costs time and money ;) ... in this case simplicity, readability, manageablility.
1st solution
Common mutation, f.e. named 'change' with changeType parameter.
Of course that requires API change - you need a new resolver.
2nd solution
Using graphql-tag you can construct any query from the string. Take an inspiration from this answer - with 'classic graphql HOC' pattern.
This solution doesn't require API change.
I think using two different Mutation components does not make sense. If I understand correctly, there can be two ways to solve your problem.
Using Apollo client client.mutate function to do manual mutation based on the state and set mutation and variables properties based on the new state. To access the client in current component, you need to pass along the client from parent component where it was created to child components where mutation is taking place.
Using single Mutation component inside render method of your component and setting mutation and variables attributes based on the state variable.
The approach that you are using is working as you said, but to me looks like you are delegating some logic to the UI that should be handled by the underlying service based on the isSelected input.
I think that you should create a single mutation for ADD_STUFF and REMOVE_STUFF, I would create the ADD_OR_REMOVE_STUFF mutation, and choose the add or remove behavior on the resolver.
Having one mutation is easier to maintain/expand/understand, if the logic requires something else besides add/remove, for example if you have to choose add/remove/update/verify/transform, would you nest 5 mutations?
In the previous case the single mutation could be named MULTI_HANDLE_STUFF, and only have that one mutation called from the UI.
Can the below be achieved with graph ql:
we have getusers() / getusers(id=3) / getusers(name='John). Can we use same query to accept different parameters (arguments)?
I assume you mean something like:
type Query {
getusers: [User]!
getusers(id: ID!): User
getusers(name: String!): User
}
IMHO the first thing to do is try. You should get an error saying that Query.getusers can only be defined once, which would answer your question right away.
Here's the actual spec saying that such a thing is not valid: http://facebook.github.io/graphql/June2018/#example-5e409
Quote:
Each named operation definition must be unique within a document when
referred to by its name.
Solution
From what I've seen, the most GraphQL'y way to create such an API is to define a filter input type, something like this:
input UserFilter {
ids: [ID]
names: [String]
}
and then:
type Query {
users(filter: UserFilter)
}
The resolver would check what filters were passed (if any) and query the data accordingly.
This is very simple and yet really powerful as it allows the client to query for an arbitrary number of users using an arbitrary filter. As a back-end developer you may add more options to UserFilter later on, including some pagination options and other cool things, while keeping the old API intact. And, of course, it is up to you how flexible you want this API to be.
But why is it like that?
Warning! I am assuming some things here and there, and might be wrong.
GraphQL is only a logical API layer, which is supposed to be server-agnostic. However, I believe that the original implementation was in JavaScript (citation needed). If you then consider the technical aspects of implementing a GraphQL API in JS, you might get an idea about why it is the way it is.
Each query points to a resolver function. In JS resolvers are simple functions stored inside plain objects at paths specified by the query/mutation/subscription name. As you may know, JS objects can't have more than one path with the same name. This means that you could only define a single resolver for a given query name, thus all three getusers would map to the same function Query.getusers(obj, args, ctx, info) anyway.
So even if GraphQL allowed for fields with the same name, the resolver would have to explicitly check for whatever arguments were passed, i.e. if (args.id) { ... } else if (args.name) { ... }, etc., thus partially defeating the point of having separate endpoints. On the other hand, there is an overall better (particularly from the client's perspective) way to define such an API, as demonstrated above.
Final note
GraphQL is conceptually different from REST, so it doesn't make sense to think in terms of three endpoints (/users, /users/:id and /users/:name), which is what I guess you were doing. A paradigm shift is required in order to unveil the full potential of the language.
a request of the type works:
Query {
first:getusers(),
second:getusers(id=3)
third:getusers(name='John)
}
I'm creating a project to implement GraphQL around an existing API, and I'm trying to add new Scalar types (id & title respectively) to provide structure around my query.
This is the query schema I'm aiming for:
query{
allPlaylists {
id
title
}
}
I've read the gem's documentation regarding Scalar Types, but it's very unclear where I should place new ScalarType definitions.
Here is a snippet of my query, my full repo is also saved on GitHub:
// query_type.rb
Types::QueryType = GraphQL::ObjectType.define do
name "Query"
# Add root-level fields here.
# They will be entry points for queries on your schema.
field :allPlaylists, types.String do
description "Playlists that belong to the user"
resolve ->(obj, args, ctx) {
Playlist.all.map { |x| x }
}
end
end
As you can see, I currently only have the allPlaylists root-level query defined.
Though the documentation is fairly unclear about this, I do plan to submit a PR to help clarify this once I strike a solution. Alternatively, if there are any working examples I can refer to it'd be very much welcomed.
Per some clarification from the gem contributors— defining an Object Type is the correct tool for this job, rather than a Scaler Type.
I want to use the elastic4s api to delete and create templates.
I couldn't find an api to create a template with a given content, only create by providing a name.
Not sure how to use the IndexTemplateDsl.
Is this the right direction?
You create the template with a name, and then specifying the pattern match for that template, then you can add your mappings.
val req = create template "my_template" pattern "matchme.*" mappings(
mapping("sometype1").fields(
stringField("field1"),
geopointField("field2")
),
mapping("sometype2").fields(
stringField("field3"),
intField("field4")
)
)
client.execute(req)
So it's very similar to creating a normal index.