I'm creating a query but i came a section when i don't have idea that how do it. I have one array that have for example two items
//filter array
const filterArray=r.expr(['parking', 'pool'])
and also i have one table with follows records:
[
{
"properties": {
"facilities": [
"parking"
],
"name": "Suba"
}
},
{
"properties": {
"facilities": [
"parking",
"pool",
"pet friendly"
],
"name": "Kennedy",
}
},
{
"properties": {
"facilities": [
"parking",
"pool"
],
"name": "Soacha"
}
},
{
"properties": {
"facilities": [
"parking",
"pet friendly",
"GYM"
],
"name": "Sta Librada"
}
},
]
I need filter the records with the array but i need that record has all items of array filter. If the record has more item of array filter not is problem, i need if contains all items of array filter get that record. On this case I need all records that have the facilities "pool" and "parking"
Current query
Current query but it also return records with one or two items of the filter array
r.db('aucroom').table('hosts')
.filter(host=>
host('properties')('facilities').contains(val=>{
return filterArray.contains(val2=>val2.eq(val))
})
)
.orderBy('properties')
.pluck(['properties'])
results that I desire wait
Like the image example:
If you want a strict match of two arrays (same number of elements, same order), then use .eq()
array1.eq(array2)
If you want the first array to contain all elements of the second array, then use .setIntersection(), just note array2 should contain distinct elements (a set):
array1.setIntersection(array2).eq(array2)
Using http://fusejs.io/
In just about all situations, I'm finding that the 'indices returned contain pretty much the entire string.
For a very simple example, if you go to fusejs.io, and change the first object (in 'step 1' on the left) to
{
title: "so ummmmmm Old Man's War is a book about a thing",
author: {
firstName: "John",
lastName: "Scalzi"
}
},
then tick 'Include matches' (in 'step 2' in the middle)
the resulting indices matches most of the strong, including parts that are obviously way off:
"matches": [
{
"indices": [
[
0,
0
],
[
2,
2
],
[
4,
10
],
[
14,
23
]
],
"value": "so ummmmmm Old Man's War is a book about a thing",
"key": "title",
"arrayIndex": 0
}
]
whereas I'm expecting it to just return the matched part of the string, like so:
"matches": [
{
"indices": [
[
14,
23
]
],
"value": "Man's War",
"key": "title",
"arrayIndex": 0
}
]
I've tried it in my own app and seeing similar results across a large dataset. The matching itself is quite accurate - it's just the highlighting via matches[i].indices that's wrong. It seems to always match up to the matched string, and also sometimes far beyond. Am I going bonkers? Or is this just not possible with fuse.js?
Thanks!
P.S. Can someone please let me know if I'm supposed to include or not include the 'javascript' tag on a library question like this?
I want to use this data (below) as a data source for a d3.js program:
{
"component": {
"name1": {
"graphname": {
"title": "foo",
"data": [
{"data": "DATE IN ISOFORMAT", "value": 5},
{"data": "DATE IN ISOFORMAT", "value": 10}
]
}
},
"name2": {
"graphname": {
"title": "foo",
"data": [
{"data": "DATE IN ISOFORMAT", "value": 5},
{"data": "DATE IN ISOFORMAT", "value": 10}
]
}
}
}
"component2": {...
}
D3 accepts only array data? How i can manipulate it to work?
I want to graph for all component any "graphname" aggregated by "name"
Any tips?
D3 does not just accept arrays as data sources, but for looping purposes, arrays are much more convenient than JavaScript objects ("dicts"). There is a very easy way to convert objects to arrays, though. If your object above were called d, then its corresponding array can be created with:
var dlist = d3.entries(d);
Now dlist will be something like:
[ { key: 'component',
value: { name1: ..., name2: ... } },
{ key: 'component2',
value: { name1: ..., name2: ... } } ]
The original dict has been remapped into an array of "records," each with key and value pairs. This "array of records" pattern is very common in D3 work, and JavaScript in general. If you need to loop over the sub-structures (e.g. the name1, name2, ... values, d3.entries can be applied at multiple levels of the original structure, as those dict-to-list transforms are required.
Since this answer is called out in the comments as wrong, here's a working example of using an object ("dict") as a data source for a D3 program: first in a simple loop, then secondarily using the idiomatic d3 .data(...).enter() pipeline.
I have a collection that looks like the ff:
{
"word":"approve",
"related" : [
{
"relationshipType" : "cross-reference",
"words" : [
"note"
]
},
{
"relationshipType" : "synonym",
"words" : [
"demonstrate",
"ratify",
]
}
],
},
{
"word": "note",
"related" : [
{
"relationshipType" : "synonym",
"words" : [
"butt",
"need",
],
},
{
"relationshipType" : "hypernym",
"words" : [
"air",
"tone",
]
},
{
"relationshipType" : "cross-reference",
"words" : [
"sign",
"letter",
"distinction",
"notice",
]
},
],
}
I want to group/categorize all the objects which have a word in another object, be it
the name (as the cross-reference field of 'approve', has note. searches for the word 'note'.
or
the word is in another object's related words. like having a synonym of 'ratify' under 'approve' then looking for other objects that have have 'ratify' in any field of their related words.
Then save these to a new collection called categories.
result should Be:
{
"category": 1,
"words":["approve","note"],
}
...and the value of the word field for all the linked objects in the words array.
Any way how to do this.. i'm thinking about some sort of recursion in checking links but i'm not sure how to implement. another potential problem is going back to the parent layer creating an infinite loop of sorts.
and is it possible through map reduce?
EDIT: clarity.
I have a collection of JSON values that has 3 levels:
cluster > segment > node
Where each cluster is made of segments and each segment is made up of nodes. I am trying to figure out how to represent this as a JSON object and I am unsure how to create the structure.
Each node contains an id and a reference to its segment id and cluster id. I have written up a test object like this:
var customers = [
{
"cluster" :
{"flights":4, "profit":5245, "clv":2364,
"segment" :
{ "flights":2, "profit":2150, "clv":1564,
"node" :
{ 'xpos': 1, 'ypos': 2 }// closes node
}// closes segment
}//closes cluster
},
{
"cluster" :
{"flights":4, "profit":5245, "clv":2364,
"segment" :
{ "flights":2, "profit":2150, "clv":1564,
"node" :
{ 'xpos': 1, 'ypos': 2 }// closes node
}// closes segment
}//closes cluster
}
];
The part that feels a bit flaky is the way segment and node are nested. I am not getting any errors but is this the best way to represent this data?
EDIT:
Thanks for the answers, it definitely pointed me in the right direction as far as tools to use (jsonlint) and get a better understanding of structuring data in json. They're all correct answers which shows me that it was a pretty basic question. Thanks again.
the nature of json you have is perfectly valid (the idea of an object nested in an object) if not syntactically correct (didn't verify that all your commas were in the right place).
however, you dont have what you said you wanted, which is a collection of segments in a cluster, and a collection of nodes in a segment.
change it to be
[{
"cluster": {..,
"segments": [{ <--- note the array -- you now have a collection
"name": 'segment1', <- optional, just here to show multiple segments
"nodes": [{....}] <-- same here
},
{
"name": 'segment2',
"nodes": [{....}]
}]
}
}]
I think this looks alright for the most part. However, note the following:
JSON key and values should be in double quotes"and not single quotes'. Look at yourxposandypos` values to see what I mean. I usually use JSONLint to ensure that my JSON is valid.
You say that clusters have a collection of segments and segments have a collection of nodes. This might be best represented as arrays.
It also looks like you want multiple clusters. That is also best expressed as an array.
So something of the form (greatly exaggerated the indentation, hopefully that will help):
{
"cluster" : [
{
"flights": 4,
"profit": 5245,
"clv": 2364,
"segment" : [
{
"flights": 2,
"profit": 2150,
"clv": 1564,
"node" : [
{
"xpos": 1,
"ypos": 2
},
{
//node 2
}
]
},
{
//segment 2
}
]
},
{
//next cluster
}
]
}
There is nothing wrong with the nesting, however, if each cluster can contain multiple segments, and each segment can in-turn have multiple nodes, then you ought to use an array.
{
"cluster": {
"flights": 4,
...,
"segments": [ // segments is an array
{
"flights": 6,
"nodes": [ // nodes is an array
{ "xpos": 4, "ypos": 6 },
{ "xpos": 1, "ypos": 6 },
{ third node },
...
]
},
{ second segment },
...
]
}
}
Seems fine to me, though out of habit I check everything in http://www.jsonlint.com and the slightly 'fixed' version validates (remove your single quotes and ensure you name the structure):
{
"customers": [
{
"cluster" : {
"flights": 4,
"profit": 5245,
"clv": 2364,
"segment" : {
"flights": 2,
"profit": 2150,
"clv": 1564,
"node" : {
"xpos": 1,
"ypos": 2
}
}
}
},
{
"cluster" : {
"flights": 4,
"profit": 5245,
"clv": 2364,
"segment" : {
"flights": 2,
"profit": 2150,
"clv": 1564,
"node" : {
"xpos": 1,
"ypos": 2
}
}
}
}
]
}
As a note, if you were to let jQuery or another plugin do the 'JSONification' it would turn out the same, as has also been noted, you're not representing the segments, etc as a collection (this is where I personally find building the object to be an easier representation).
.. ala (but build your object out):
var stuff = {};
stuff.customers = [];
stuff.customers[stuff.customers.length] = new Cluster();
stuff.customers[i].segment[stuff.customers[i].segment.length] = new Segment();
...etc.
...blah blah fill out object
$.toJSON('{"customerArrary":' + stuff + '}');
function cluster(){
this.flights;
this.profit;
this.clv;
this.segment = [];
}
function Segment(){
this.flights;
this.profit;
this.clv;
this.node = [];
}
function Node(){
this.xpos;
this.ypos;
}
Here's an improvement to the logic with no loss of meaning:
var customers = [
{
"ID" : "client ABC",
"cluster" : { "ID": "cluster 123", "flights": 4, "profit": 5245, "clv": 2364 },
"segment" : { "ID": "segment 456", "flights": 2, "profit": 2150, "clv": 1564 },
"node" : { "xpos" : 1, "ypos" : 2 }
}, {
"ID" : "client DEF",
"cluster" : { "ID": "cluster 789", "flights": 4, "profit": 5245, "clv": 2364 },
"segment" : { "ID": "segment 876", "flights": 2, "profit": 2150, "clv": 1564 },
"node" : { "xpos" : 1, "ypos" : 2 }
}
];
In the above, the actual 'levels' are
clusters > flights etc & segments > flights etc & nodes > xpos etc
which could also be written:
level 1: clusters
level 2: flights, profit, & clv (note: values are unique from segments tho labels are identical)
level 1: segments
level 2: flights, profit, & clv
level 1: nodes
level 2: xpos & ypos
Ok, let's agree the OP's example (as initially written) can meet the strict mechanical requirements of the JSON spec.
However, the OP describes 3 'levels', illustrating them as cluster > segment > node. The word 'level' and the arrows only make any sense if there is a semantic relationship between those objects. After all, 'levels' must relate to each other in a hierarchy, inheritance, sequence or some similarly layered fashion.
The original example gives no hint of the relationship between any part of a cluster and any part of a segment or any part of a node; it gives no way to guess what the relationship should be. The labels just sit adjacent to each other in the example, with a few extraneous braces around them.
Without an apparent relationship to encode, each of these keys most logically names a unique property of a 'customer' object--that is to say, each customer has clusters, segments and nodes. Each property is clearly labeled, and each can happily coexist in a flat structure. If OP has more info on relationships that require levels, the structure is easy to modify.
In short, nesting should have a semantic purpose; if it does not, markers of nesting should be omitted. As presented, much of the JSON syntax in the OP's example had no apparent meaning and introduces logical issues. The revision resolves these issues as well as possible with given information.