I am trying to create a v-select that displays categories. I create the categories in firestore. articles(collection) > documentId(auto gen'd) > categories(map) with "bicyles" array and musical instruments array. The vuex getter with "{{this.categories}}" gets:
[ { "categories": { "musicalInstruments": [ "guitar", "viola" ], "bicycles": [ "mountainBike", "street" ] } } ]
How can I create a v-select?
currently this is all i have:
<v-select
filled
hide-details="auto"
return-object
label="Catagory"
:items="this.categories"
#input="updateCategory"
>
</v-select>
Is my firestore structure for categories adequate or am I overlooking something? I do want to filter this in search eventually. What is the best firestore structure? and if this is adequate, how should i create a v-select with this object? just not sure what to do, really. THank you.
Related
I have a music app that has a job to find music recommendations based on a tag id.
There are two entities involved:
Song - a song record contains its name and a list of music tag ids (genres) this song belongs to
MusicTag - the music tag itself, includes id, name etc.
Data is currently stored in MongoDB.
The Songs collections in mongo have millions of songs, and each song has an average of 7 tag ids.
The MusicTags has about 30K records.
The Songs collection looks like that:
[
{
name: "Metallica - one",
tags: [
"6018703624d8a5e8efa1b76e", // Rock
"601861cc8cef62ba86765017", // Heavy metal
"5fda07ac8db0615c1c503a46" // Hard Rock
]
},
{
name: "Metallica - unforgiven",
tags: [
"6018703624d8a5e8efa1b76e", // Rock
"5fda07ac8db0615c1c503a46", // Metal
]
},
{
name: "Lady Gaga - Bad Romance",
tags: [
"5fc7b9f95e38e17282896b64", // Pop
"5fc729be5e38e17282844eff", // Dance
]
}
]
Given the tag "6018703624d8a5e8efa1b76e" (Rock), I want to query the Songs collection and find all songs that have Rock tag in their tags array.
In Mongo this is the query i'm doing:
db.songs.find({ tags: { $in: [ObjectId("6018703624d8a5e8efa1b76e")] }});
The performance of it is very bad (between 10 to 40 seconds and getting worst as long as the collection grows), I tried to index Mongo in various ways (the table contains more data that involve in the search, such as score and duration, but it's not relevant for now) but my queries are still take too long, I can't explain it (and I read a lot of official and unofficial stuff) but I have a feeling that holding the data in this nested form makes the index worthless and somehow still make a full scan on the table each time - but I can't prove it (the Mongo "explain" not really explained me something :) )
I'm thinking of using ElasticSearch for it, sync all songs data, and query it instead of the Mongo that will stay as the data SSOT and other lightweight ops.
But then the question remains open and I want to make sure: is in Elastic I can hold the data in that form (nested array inside song) or I need to represent it differently (e.g. flat it so every record will be song_tag index etc?
Thanks.
Elasticsearch doesn't offer a dedicated array type so what you'd typically do is define the mapping based on the type of the individual array items -- in your case a keyword:
PUT songs
{
"mappings": {
"properties": {
"tags": {
"type": "keyword"
}
}
}
}
Then you'd index the docs:
POST songs/_doc
{
"name": "Metallica - one",
"tags": [
"6018703624d8a5e8efa1b76e",
"601861cc8cef62ba86765017",
"5fda07ac8db0615c1c503a46"
]
}
and query the tags:
POST songs/_search
{
"query": {
"bool": {
"must": [
{ ... other queries },
{
"terms": {
"tags": [
"6018703624d8a5e8efa1b76e" // one or more
]
}
}
]
}
}
}
The tags are unique keywords but are not human-readable so you'd need to keep the map of them vs. the actual genres somewhere. Since the genres are probably set once and rarely, if ever, updated, you could use nested fields too. But your tags would then become an array of key-value pairs:
POST songs/_doc
{
"name": "Metallica - one",
"tags": [
{
"tag": "6018703624d8a5e8efa1b76e",
"genre": "Rock"
}
...
]
}
The mapping would be slightly different and so would be the queries but now you wouldn't need the translation map, plus you could query or aggregate by human-readable values -- tags.genre.
I've implemented tree structure and want to save items to database. Every item has "children" field with list of child nodes.
But if I send PUT request with something like this:
https://localhost:9001/ws410/rest/pdsfamilies/8796093098749
{
"children": [
{
"pk": "8796093164285"
}
]
}
I'm getting response 200 OK but of course "children" list doesn't update. If I pull the item using GET again, it doesn't contain that change.
What am I doing wrong?
The solution was weird nested object structure like this:
{
"children": {
"pdsFamily" : [
{
"pk": "8796093164285"
}
]
}
I don't know why another property pdsFamily was needed.
Also another weird thing is that in the response from GET I'm getting similar structure but the property is all lowercase pdsfamily... I have to create separate dtos for response and request just because of that...
Example:
If I have a database, let's call it world, then I can have a collection of countries.
The collection can have documents, one example on a document:
"_id" : "hiqgfuywefowehfnqfdqfe",
"name" : "Italy",
cities : {{"_id": "ihevfbwyfv", name : "Napoli"}, {"_id: "hjbyiu", name: "Milano"}}
Why should I or when should I create a new collection of documents, I could expand my documents inside my world collection instead of creating a new collection.
Is creating a new collection not like creating a new domain?
Separate collections offer the greatest querying flexibility. Separate collections are good if you need to select individual documents, need more control over querying, or have huge documents and they require more work. Selecting embedded documents is more limited. A document, including all its embedded documents and arrays, cannot exceed 16 MB. Embedded documents are easy and fast, good when you want the entire document, the document with a $slice of comments, or with no comments at all.
A world collection should look like this:
You should create a document / country.
The above is a single document:
{
"_id": "objectKey", //generated by mongo
"countryName": "Italy",
"cities":[
{
"id": 1,
"cityName": "Napoli"
},
{
"id": 2,
"cityName": "Milano"
}
],
}
Try to expend this collection with other countrys but there are some other situations where you should consider creating a new collection and try to create some sort of relation:
If you use mmapv1 storage engine and you wish to add cities over the time you should consider relational way cuz mmapv1 does not tolerate rapidly growing arrays. If you create a document with mmapv1 the storage engine gives a paddign to the document for growing arrays. If this paddign is filled then the document will be relocated in the hard drive with will result disc fregmentation and performace loss. Btw the default storage is Wiredtiger now which does not have this problem.
Do not nest documents too deeply. It will make your documents hard to run complex queries on. For an example do not create documents like the following:
{
"continentName": "Europe",
"continentCountries: [
{
"countryName": "France",
"cities": [
{
"cityId": 1,
"cityName": "Paris"
},
{
another country
}
]
},
{
another country
}
],
"TimeZone": "GMT+1"
],
"continentId": 1
}
In this situtation you should create a continent property for your country object with the continent name or id in it.
With mongodb you should avoid relations most of the time but its not forbidden to create them. Its way better to create relation then nest document too deeply but the best solution is to flip hierarchical level of the document documents for an example:
use 'county->cities, countinentId, etc...' instead of 'continent->country->city'
useful reading: https://docs.mongodb.org/manual/core/data-modeling-introduction/
I have collection People.
Every person in this collection has favorite color. here example of person
{
id:123,
color:'red',
...
...
}
What is an elegant way to go through collection People, and
query all possible colors form that collection and how many people love that color?
Example of output:
'green':125,
'yellow': 76
etc...
Many thanks for help!!
Use the aggregation framework.
db.collection.aggregate( [
{$group: {_id:"$color",
numLiking:{$sum:1}
} }
] );
You'll get back something like:
[ { _id:"red", numLiking:7 }, { _id:"green", numLiking:17 }, ... ]
I am having some difficulty structuring my data so that I can benefit from reactivity in Meteor. Mainly nesting arrays of objects makes queries tricky.
The three main views I am trying to project this data onto are
waiter: shows order for one table, each persons meal (items nested, essentially what I have below)
kitchen manager: columns of orders by table (only needs table, note, and the items)
cook: columns of items, by category where started=true (only need item info)
Currently I have a meteor collection of order objects like this:
Order {
table: "1",
waiter: "neil",
note: "note from kitchen",
meals: [
{
seat: "1",
items: [ {n: "potato", category: "fryer", started: false },
{n: "water", category: "drink" }
]
},
{
seat: "2",
items: [ {n: "water", category: "drink" } ]
},
]
}
Is there any way to query inside the nested array and apply some projection, or do I need to look at an entirely different data model?
Assuming you're building this app for one restaurant, there shouldn't be many active orders at any given time—presumably you don't have thousands of tables. Even if you want to keep the orders in the database after they're served, you could add a field active to separate out the current ones.
Then your query is simple: activeOrders = Orders.find({active: true}).fetch(). The fetch returns an array, which you could loop through several times for each of your views, using nested if and for loops as necessary to dig down into the child objects. See also Underscore's _.pluck. You don't need to get everything right with some complicated Mongo query, and in fact your app will run faster if you query once and process the results however many times you need to.