Coming from a mongodb background, I'd like to set up a document with an embedded collection.
For instance if I have a profile object
Profile
name : string
followers : [
name: string
]
such that it has an embedded collection of followers.
Is there a way that I can create an index on Profile so that I can query for all profiles where Profile.Followers includes myUsername?
In short I can query for profiles I'm following from a dynamoDB table?
In mongo I can easily do this by setting up an index on Profile.followers and doing an $in query. Is there something similar for dynamodb?
This documentation suggests there is nothing like an in clause
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html
Currently DynamoDB does not support indices for non scalar types (i.e. Set, List, or Map data types - see here: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html). If you have a separate users table, you can keep track of all profiles you are following in a Set/List attribute.
Related
There is a way to batch get documents after you specified exactly all the file paths using
https://firestore.googleapis.com/v1/projects/projectName/databases/dbName/documents:batchGet.
And there is a way to get all documents and their fields under a collection by sending a GET to https://firestore.googleapis.com/v1/projects/projectName/databases/dbName/documents/collectionName
I ideally want to make a batch request to get document fields for all documents under an array of collections. Is there a way to do this without knowing the document names of every document I intend to get?
Example
I have a structure like projects/projectName/databases/dbName/documents/Inventory/productId/variantId/*location*
Each productId is a document, and under this it has a collection for each variant, and within that collection are documents for each location, that contains a field count.
For a basket, I want to get all inventory counts for all inventory locations, for each productId/variantId in that bas
It is not possible to get all documents based on an array of collection names.
You can use a collection group query and search all collections of a given name, but then you must know the path of each document you want to read.
Alternatively, you can get all documents under a specific path, but then you can't filter by ID anymore, and the collections have to be under a path - not an array.
I can't manage to determine what is the better way of organizing my database for my app :
My users can create items identified by a unique ID.
The queries I need :
- Query 1: Get all the items created by a user
- Query 2 : From the UID of an item, get its creator
My database is organized as following :
Users database
user1 : {
item1_uid,
item2_uid
},
user2 : {
item3_uid
}
Items database
item1_uid : {
title,
description
},
item2_uid : {
title,
description
},
item3_uid : {
title,
description
}
For the query 2, its quite simple but for the query 2, I need to parse all the users database and list all the items Id to see if there is the one I am looking for. It works right now but I'm afraid that it will slow the request time as the database grows.
Should I add in the items data a row with the user id ? If yes the query will be simpler but I heard that I am not supposed to have twice the same data in the database because it can lead to conflicts when adding or removing items.
Should I add in the items data a row with the user id ?
Yes, this is a very common approach in the NoSQL world and is called denormalization. Denormalization is described, in this "famous" post about NoSQL data modeling, as "copying of the same data into multiple documents in order to simplify/optimize query processing or to fit the user’s data into a particular data model". In other words, the main driver of your data model design is the queries you plan to execute.
More concretely you could have an extra field in your item documents, which contain the ID of the creator. You could even have another one with, e.g., the name of the creator: This way, in one query, you can display the items and their creators.
Now, for maintaining these different documents in sync (for example, if you change the name of one user, you want it to be updated in the corresponding items), you can either use a Batched Write to modify several documents in one atomic operation, or rely on one or more Cloud Functions that would detect the changes of the user documents and reflect them in the item documents.
I have 3 collections
Companies: [{name:'Lamy'}]
Pens : [name:'Safari', company:ref::companies]
Writing Samples :[{title:'Post title', pen:ref::pens }]
I want to get all writing samples from from a particular pen company.
Is it possible to filter based on field values in a referenced document or do I need to restructure my firestore?
Example
const company = db.collection('companies').doc(form.penCompany);
db.collection('samples').where('pen.company', '==', company)
My guess is no and that I need to restructure my DB to include the company information nested in the sample.
You will need to restructure. A query on a collection can't reference documents from other collections - there are no SQL-like joins. Everything in the query must be in the same collection. This means you might have to duplicate data between collections. This is a common technique when working with NoSQL. It's call "denomralization".
I have the following document structure in firebase:
{
typeId: number,
tripId: number,
locationId: string,
expenseId: number,
createtAt: timestamp
}
I want to query this collection using different 'where' statement everytime. Sometimes user wants to filter by type id and sometimes by locationId or maybe include all of the filters.
But it seems like I would need to create a compound index of each possible permutation? For example: typeId + expenseId, typeId + locationId, location + expenseId, etc, otherwise it doesn't work.
What if I have 20 fields and I want to make it possible to search across all of these?
Could you please help me to construct a query and indexes for the following requirement: Possibility to query across all fields, query can contain one, two, three, all or no fields included in where clause and always has to be ordered descending order by createdAt.
Cloud Firestore automatically creates indexes for the individual fields of your documents. So it can already filter on each field without you have to manually add these indexes.
In many cases it is able to combine these indexes to allow queries on field combinations, by performing a so-called zig-zag-merge-join.
Custom additional indexes are typically only needed once you add an ordering-clause to your query, in addition to filter clauses. If you have such a case, the Firestore client will log an error telling you exactly what index to create (with a link to the Firestore console that is prepopulated to created the index for you).
Im looking to have a document, which contains a collection of references to other documents. Like a Project that has a collection of Users, but the entries are Reference types to users from the top level Users collection.
I can't see a way of adding a Reference type to a Collection, It looks like you must create a Document first and then have a field in that doc that is the reference to the user doc - but that is just adding extra work.
When getting the collection data, you will have to first get the Document in the collection, and then using the field for the reference get the User Document.
It would be far simpler to have a nested array of values.
What is the best way to store a collection of references ?
A Reference is a field type, and fields must be in documents. You indeed cannot add References directly to a collection. But from your description I don't think this requires extra dummy documents:
Im looking to have a document, which contains a collection of references to other documents. Like a Project that has a collection of Users, but the entries are Reference types to users from the top level Users collection.
This sounds like you have two top-levels collections: Projects and Users. A document under Projects then has a nested map of user references.
If I misunderstood your model, then indeed: you will need to create a document to store your references to users. This is inherent to the Firestore data model, and can't be changed.