I am learning about FaunaDB and on running the following script in Fauna Shell I get the error:
Error: [
{
"position": [
"map",
"expr",
"get"
],
"code": "invalid argument",
"description": "Ref or Set expected, String provided."
}
]
Query I am trying to run:
Map(Paginate(Match(Index("todo_tasks"))), Lambda(x => Get(x)))
Thanks all. I've figured it out. The problem was that the index I created was not returning the refs which is required by Get. Therefore, I created a new Index which returned the refs and used it instead and it worked. Thanks again.
Match is supposed to have two arguments. I think what's happening is that it is defaulting to matching against an empty string. You have to tell Fauna what you're Matching your index with. Have you tested your index? You can go to the fauna client and click on indexes. You should be able to select "string", "number" or "FQL" and enter a value that would return the document you're searching for.
But in order to properly determine what the second argument should be, you need to provide more information as to how your index is constructed for your todos. If the index is on a data type Todo, you need to provide a Ref to that Todo as your second argument in Match.
Related
Like many others I've been getting this error when using Sequelize with Express and Express-handlebars:
Handlebars: Access has been denied to resolve the property "first_name" because it is not an "own property" of its parent.
You can add a runtime option to disable the check or this warning:
See https://handlebarsjs.com/api-reference/runtime-options.html#options-to-control-prototype-access for details
Handlebars: Access has been denied to resolve the property "last_name" because it is not an "own property" of its parent.
You can add a runtime option to disable the check or this warning:
See https://handlebarsjs.com/api-reference/runtime-options.html#options-to-control-prototype-access for details
I have found some answers on how to get around this. ie: allowProtoMethods, or adding npm install #handlebars/allow-prototype-access
What I'm curious about is, is there a proper way to handle the data or exclude the proto methods from the sequelize response?
I may not be understanding the issue at hand properly, so if that's the case I apologize. I'm just looking for the "right" way to deal with this.
Edit: To clarify a little further, I'm seeking to do things in a way that will produce the most secure application.
From handlebarsjs.com:
Using these properties may open security holes.
UPDATE!
I'm still trying to work this issue out, but I've noticed an interesting behavior.
Nested objects seem to trigger this issue.
It seems to trigger when the data in a nested object is accessed/rendered on the html page (exa: {{contact.first_name}}
sometimes it will have nested dataValues objects within the object and sometimes it won't.
I'd provide an example including dataValues, but it hasn't displayed like that for a while.
Object being returned:
{
"id": 3,
"email": "email2#email.com",
"password": "$2b$10$fOGiJC6NgUTR4qIt7/R7vuwpaFb3PUl9ks2vHBEkLnOUmRN0tEFue",
"kind": "user",
"createdAt": "2020-08-16T04:37:58.000Z",
"updatedAt": "2020-08-16T04:37:58.000Z",
"Contact": {
"id": 3,
"first_name": "Jane",
"last_name": "Doe",
"gender": "female",
"city": "Long Beach",
"state": "CA",
"zip": 12345,
"phone_number": 1234567891,
"createdAt": "2020-08-16T04:37:58.000Z",
"updatedAt": "2020-08-16T04:37:58.000Z",
"UserId": 3
},
"Props": []
}
I'm not necessarily seeing any other explicit types of data that trigger this error message. (That's not to say that there aren't any, but so far every data type and script that I've passed hasn't caused a problem.)
Data I was having a problem with: This data is from a Sequelize query response shown above.
let hbsObject = {
user: data[0],
contact: data[0].Contact
};
Notes about what happened with this data:
I used a promise to chain several queries at once.
User was queried, and contact was included in that query, so there were nested objects/data in the response. (obviously)
When I tried to render the first and last names from the data I was receiving the error message.
Data that seems to have solved my error:
let user = {
id: data[0].id,
email: data[0].email,
kind: data[0].kind,
createdAt: data[0].createdAt,
updatedAt: data[0].updatedAt,
};
let hbsObject = {
user: user,
contact: data[0].Contact.dataValues,
};
It's strange because sometimes when you view the data in the console, dataValues will be visible, and sometimes it won't. However, when you access it as I showed above the error is removed.
Current Conclusion
The data you are seeking to access on the handlebars page via the handlebars object must not be in a nested object.
What does that mean?
It seems to mean that you must either deconstruct it prior to passing the data to the page either manually (like I did with user) or by sending the data from the object 1 level at a time (like I did with contact).
If anyone can build on this or expand additional information I would greatly appreciate it! I'll edit again if more information becomes available.
UPDATE2
An array of objects is inaccessible as it is a list of objects nested in an array. This makes {{#each x}} a challenge. Individual data has been accessible with the method above.
UPDATE3
I was unable to find any clear solution to this issue. In the end I just allowed the proto methods with the handlebars/allow-prototype-access package.
As long as you're the only one that has access to your template/you absolutely 100% trust whoever also has access to your template, then it shouldn't really be a problem. If that isn't the case, I'd suggest using something other than handlebars for now.
0
If you are using MySQL, sequelize, use raw query options {raw: true} and if you are using relationships, you can use {nest: true}, eg:
users = await User.findAll({
where: { username: "SimonAngatia" },
include: [{ model: Tweet, as: "Tweets" }],
raw: true,
nest: true,
}).catch(errorHandler);
refer here: Sequelize, convert entity to plain object
Could not find this answer online, so decided to post the question then the answer.
I created a table in the capabilities.json file:
"dataRoles": [
{
"displayName": "Stakeholders",
"name": "roleIwant",
"kind": "GroupingOrMeasure"
}
...
"dataViewMappings": [
{
"table": {
"rows": {
"select": [
{
"for": {
"in": "roleIwant"
}
}
]
}
}
}
]
I realized that I could not simply set, for instance, legend data from the first category, because the first category comes from the first piece of data the user drags in, regardless of position. So if they set a bunch of different pieces of data in Power BI online, for instance, then remove one, the orders of everything get messed up. I thought the best way to settle this would be to identify the role of each column and go from there.
When you click on show Dataview, the hierarchy clearly shows:
...table->columns[0]->roles: { "roleIwant": true }
So I thought I could access it like:
...table.columns[0].roles.roleIwant
but that is not the case. I was compiling using pbiviz start from the command prompt, which gives me an error:
error TYPESCRIPT /src/visual.ts : (56,50) Property 'roleIwant' does not exist on type '{ [name: string]: boolean; }'.
Why can I not access this in this way? I was thinking because natively, roles does not contain the property roleIwant, which is true, but that shouldn't matter...
The solution is actually pretty simple. I got no 'dot' help (typing a dot after roles for suggestions), but you can use regular object properties for roles. The command for this case would be:
...table.columns[0].roles.hasOwnProperty("roleIwant")
And the functional code portion:
...
columns.forEach((column) =>{
if(column.roles.hasOwnProperty("roleIwant")){
roleIwantData = dataview.categorical.categories[columns.indexOf(column)].values;
})
If it has the property, it belongs to that role. From here, the data saved will contain the actual values of that role! The only thing I would add on here is that if a column is used for multiple roles, depending on how you code, you may want to do multiple if's to check for the different roles belonging to a column instead of if else's.
If anyone has any further advice on the topic, or a better way to do it, by all means. I searched for the error, all over for ways to access columns' roles, and got nothing, so hopefully this topic helps someone else. And sorry for the wordiness - I tend to talk a lot.
I've read the documentation on Google's knowledge graph and from what I understand we can search for results both based on a query and based on IDs. For getting results by a query, no problem whatsoever, but when I try to retrieve them by IDs, it fails. Setting aside what query I used myself, this is the request URL I got from Google's API Explorer:
https://kgsearch.googleapis.com/v1/entities:search?ids=kg%3A%2Fm%2F01nrz4&key={YOUR_API_KEY}
and the result is:
{
"error": {
"code": 400,
"message": "Request contains an invalid argument.",
"status": "INVALID_ARGUMENT"
}
}
And I'm pretty sure that the problem is with the ids parameter. Am I missing something?
Thanks
OK, so here's the thing. Each found instance has an attribute like this: "#id": "kg:/m/0gkg6" . So in this instance the id is kg:/m/0gkg6, but when we want to run a query based on ID, we should omit the kg: part.
http://apidocs.mailchimp.com/api/2.0/campaigns/list.php
I would expect that something like
{
"apikey": "12345",
"filters": {
"list_id": "abcde",
"exact": true
}
}
to return a list of total=1 if there is one campaign with list_id = "abcde", or total=0 if there isn't (using exact=true). However, instead I get the full list. Is this by design? Am I missing some other setting to filter out all mismatches? Is there a way to deal with this?
OK, so this is what I have come up with, barring some other resolution:
When the result set is returned, do a sanity check on the first result (data.data[0]).
If there is a true match, then data.data[0].list_id = list_id
If there was no match, and the full set has come back, then data.data[0].list_id cannot = list_id
This extra step is not ideal, imo, but it does do the trick.
if data.data[0].list_id === list_id
// the list is a match, return the results
else
// the list is not a match, do something else
Here's another solution:
The full-response will provide an error object if no match
"errors": [{
"filter": "list_id",
"value": "abcde",
"code": 200,
"error": "Invalid MailChimp List ID: abcde"
}]
and an empty object for a set of matches
"errors": []
So you can first process your result by looking for this error object and making the appropriate decision.
I received some clarification from MailChimp (and post it here with permission) that this is as-intended:
To provide some more information, the behavior with the campaigns/list call completing, even with an invalid filter, is expected behavior. As you mention, an error array is included in the return, and it would be possible to check that array for any errors received to determine whether or not the call completed as expected.
I can certainly see how that may be unexpected, to receive the full list of campaigns when attempting to filter. If you'd prefer that an error would be returned, without the campaign data returned, we'd recommend adding that suggestion to our feedback form here: http://mailchimp.com/contact/feedback/ That's certainly something our developers could consider for future versions of the API.
I'm still not sure why they do it this way, but I've added feedback suggesting that they return an empty result (so as not to bulk up the response with irrelevant data), or to improve the documentation.
I'm trying to optimize my elasticsearch scheme.
I have a field which is a URL - I do not want to be able to query or filter it, just retreive it.
My understanding is that a field that is defined as "index":"no" is not indexed, but is still stored in the index.
(see slide 5 in http://www.slideshare.net/nitin_stephens/lucene-basics)
This should match to Lucene UnIndexed, right?
This confuses me, is there a way to store some fields, without them taking more storage than simply their content, and without encumbering the index for the other fields?
What am I missing?
I'm new to posting on stack exchange but believe I can help a bit!
There are a few considerations here:
Analyzing
As you don't want to do extra work you should set "index": "no". This will mean the field will not be run through any tokenizers and filters.
Furthermore it will not be searchable when directing a query at the specific field: (no hits)
"query": {
"term": {
"url": "http://www.domain.com/exact/url/that/was/sent/to/elasticsearch"
}
}
*here "url" is the field name.
However the field will still be searchable in the _all field: (might have a hit)
"query": {
"term": {
"_all": "http://www.domain.com/exact/url/that/was/sent/to/elasticsearch"
}
}
_all field
By default every field gets put in the _all field. Set "include_in_all": "false" to stop that. This might not be an issue with you as you are unlikely to search against the _all field with a URL by mistake.
I was working with a schema where countries were stored as 2 letter codes, e.g.: "NO" means Norway, and it is possible someone might do a search against the all field with "NO", so I make sure to set "include_in_all": "false".
Note: Any query where you don't specify a field explicitly will be executed against the _all field.
Storing
By default, elasticsearch will store your entire document (unanalyzed, as you sent it) and this will be returned to you in a hit's _source field. If you turn this off (if your elasticsearch db is getting huge perhaps?) then you need to explicitly set "store": "yes" to store fields individually. (One thing to notice is that store takes yes or no and not true or false - it tripped me up!)
Note: if you do this you will need to request the fields you want returned to you explicitly. e.g.:
curl -XGET http://path/index_name/type_name/id?fields=url,another_field
finally...
I would leave elasticsearch to store your whole document (as the default) and use the following mapping.
"type_name": {
"properties": {
"url": {
"type": "string",
"index": "no",
"include_in_all": "false"
},
// other fields' mappings
}
}
Source: elasticsearch documentation
There are two ways to input data into the index. Indexing and Storing. Indexing a piece of data means that it is tokenized, and placed in the inverted index, and can be searched. Storing data means it is not tokenized, or analyzed or anything, and is not added to the inverted index. It is stored in an entirely separate area, in it's full text form. It can not be searched against, but can be retrieved, in it's original form, by it's document ID.
The typical Lucene query process is to query against indexed data, and get the back Document IDs of matching documents, then to use those document IDs to retrieve the stored data for those documents, and display it to the user.
Data which is indexed, but not stored is searchable, but can not be retrieved in it's original form.
Data which is stored, but not indexed can be retrieved once you have found a hit, but is not searchable.
Data which is indexed and stored can be searched or retrieved.
Data which is neither can not be added to the index at all.
This is covered a bit in the Lucene FAQ.
You are looking for the 'index' => 'not_analyzed' mapping option.
Also, if you use the _source, you do not have to specify the store => false option.