I've been pouring over the new documentation for the Google Docs API for more efficient ways to synchronize my application's resources and I came upon the changes feed. So far, all the documentation leads me to believe that the changes feed applies to the entire documents list only without the ability to inquire about changes to a specific collection. My application doesn't care about any documents besides the ones belonging to the collections the user has specified. Does anyone know if querying a specific collection for a changes feed is possible? Thank you.
That is not possible, but the nature of the changes feed is such that it should be cheaper to grab just the latest few changes, by storing the largest timestamp. Once you have the changes feed, you can filter them by looking at the entry's #parent link, that looks like:
<link rel='http://schemas.google.com/docs/2007#parent'
type='application/atom+xml'
href='https://docs.google.com/feeds/default/private/full/folder%3A0B343'
title='Some API Documentation' />
Related
I'm making an app where it stores how many minutes a user has studied with my app. My Firestore database starts with a "users" collection, and each user has their own document that is named by their userID generated in Auth.
My question is if I read their userID document, which has many documents in its sub collections, does that count as one read or does it also count the number of documents in the sub collections as well?
Thank You in advance.
The answer here from Torewin is mostly correct, but it missing one important detail. It says:
if you retrieve a document; anywhere, it counts as a read
This is not entirely true. Cached document reads are not billed as reads. This is one important feature of the Firestore client SDKs that helps lower billing costs. If you get a single document using the source option cache (options are "cache" or "server" or "default"), then the cache will be consulted first, and you get the document without billing. The cache is also used for query results when the app is offline.
The same is true for query results. If a document comes from cache for some reason, there is no billing for that read.
I am uncertain what Torewin means by this in comments: "They recommend you make multiple reads instead of 1 big one because you will save money that way". All reads are the same "size" in terms of billing, considering only the cost of the read itself. The size of the document matters only for the cost of internet egress usage, for which there is documentation on pricing.
It's worth noting that documents can't "contain" other documents. Documents are contained in collections or subcollections. These collection just have a "path" that describes where they live. A subcollection can exist without a "parent" document. When a document doesn't exist, but a collection is organized under it, the document ID is shown in italics in the console. When you delete a document using the client API, none of its subcollections are deleted. Deletes are said to be "shallow" in this respect.
If you are referring to is it 1 read to access a Document (in this case your generatedUserID) from FireStore?
I would imagine the answer would be yes.
Any query or read from Firestore only pulls the reference that you are mapping to. For example, if you grab the 3rd document in your User -> userID -> 3rd document, only the 3rd document will be returned. None of the other documents in that collection or any of the collections besides the userID.
Does that answer your question or are you asking something completely different?
For reference: https://firebase.google.com/docs/firestore/pricing#operations
Edit: Each individual Document that is pulled from the query will be charged. For example, if you pull the parent collection (with 6 documents in it), you will be charged for all 6 documents. The idea is to only grab the documents you need or use a cursor which let's you resume a long-running query. For example, if you only want the document pertaining to use data on a specific date (if your data is set up like that), you'd only retrieve that specific document and not retrieve all of the documents in the collection for the other days.
A simple way of thinking about it is: if you retrieve a document; anywhere, it counts as a read.
I have an external editable html file (using blocks of contentEditable="true") linked in the table of contents. Using Valence, could I save the edited contents of that file to the 'Manage Files' section of that course? Started reading through the Valence docs, but thought i'd ask here before wasting too much time there. Thanks, S
I'm not quite sure what exactly your meaning. Currently, the only direct access that you have to course content through the Valence Learning Framework APIs is via the course content module-topic structure. The URL property associated with an uploaded topic file situates it within the "manage files" tree, and you can use this property to fetch the contents of a topic from the structure.
There are no API calls to in-place update the contents of a topic file; to update it, you must fetch it, delete the topic, then re-upload the updated file content to a new topic node. This may leave behind the previous topic file, unlinked from the content structure.
The current course content API design proceeds from the user scenario of roughing out the framework for a new course's content, and not necessarily maintaining or changing that course content over time. Enhancement to the course content APIs to more comfortably accomodate additional use-cases is on the roadmap, but is not currently fully scheduled and fleshed out.
My app caches Google Docs files locally and needs to update them then whey change. When I request a changes feed, the results include all items that have changed, regardless of the type of change. I only need to re-download those items whose actual content has changed; I don't need to download documents that have merely been shared with somebody new or otherwise had their metadata changed. I know that you can request that expanded ACL data be included in the changes feed, but that may not be sufficient if it will only help me detect permissions changes, and not other changes to metadata.
Is there a way to do this? The files that are being downloaded are quite large at times (5-10MB), and the accounts that I'm tracking frequently have thousands of files, so imagine my users' consternation if they're on a slow connection and my app suddenly has to re-download hundreds of files due to a simple change like a folder being shared with a new user.
Thanks!
How about the revision feed?
You can find exactly what you need.
Okay. I overlooked the simple answer hidden in the XML: there is a checksum element included in the docs feed for all documents.
I'm using acts_as_taggable_on for tagging items across my system so that they're easily searchable.
Now I have a UX problem: I'm noticing lots of places where users choose certain minor states (for example, closing a one-time help box or moving to the next javascript-run step in a given page). We have here situations that are both too minor/numerous/dynamic/fast-changing to be put into a database table (imagine having to migrate with every UX change!), and that there is a need to persist some of these choices beyond the session.
In this case, is there anything wrong with using tags to store these simple decisions? For example, user.set_tags_on(:ui, "closed_index_help") or user.set_tags_on(:ui, "tutorial_1_done"), then showing/hiding these elements in the future by looking at the user's ui_list.
Are there drawbacks to this I'm not considering or is this a prudent way to go?
Another way might be to store the information in the SESSION. You will of course have to migrate the session information to be stored in the DB rather than the cookie, but at least that way - you only have to retrieve the session once.
I'm building a web app for bookmark storage with a directory system.
I've already got these collections set up:
Path(s)
---> Directories (embedded documents)
---> Links (embedded documents)
User(s)
So performance wise, should I:
- add the user id to the created path
- embed the whole Paths collection into the specific user
I want to pick option 2, but yeah, I dunno...
EDIT:
I was also thinking about making the whole interface ajaxified. So, that means I'll load the directories and links from a specific path (from the logged in user) through ajax. That way, it's faster and I don't have to touch the user collection. Maybe that changes things?
Like I've said in the comments, 1 huge collection in the whole database seems kinda strange. Right?
Well the main purpose of the mongoDB is to support redundant data.I will recommend second option is better because In your scenario what I feel that if you embed path collection into the specific user then by using only single query you can get all data about user as well as related to path collection as well.
And if you follow first option then you have to fire two separates queries to get all data which will increase your work somewhat.
As mongodb brings data into the RAM so after getting data from one collection you can store it into cursor and from that cursor data you can fetch data from another collection. So if we see performance wise I dont think it will affect a lot.
RE: the edit. If you are going to store everything in a single doc and use embedded docs, then when you make your queries make sure you just select the data you need, otherwise you will load the whole doc including the embedded docs.