For jquerydatatable, I need to prodive a json like this:
{
rusults:[],
count: 100
}.
Before actually hitting db, I have an iqueryable. Because I only get a specific number of per page, I have to use skip and take to get result (one request) and use another request to get item count for pagination.
Please tell me how could I avoid second request?
Related
My documents all have sequential numbers, saved as a String as an ID (it's padded with 0s). When creating a new record, I first do a request for Comment.count(). Using the number returned from that, I generate the ID string. I then create an object, and save it as a new document.
var commentNumber = (result[1] + 1).toString().padStart(4, '0');
var newComment = this({
html: processedHtml,
number: commentNumber
});
newComment.save(function(err, result) {
if (err) return callback(err);
return callback(null, result);
});
The problem is, if two comments are submitted at the same time, they will get the same ID (this happens if I make 2 requests on submission instead of 1, they will both have the same ID).
How can I prevent this?
One simple option would be to create a unique index on number so that one of the requests fails.
Another would be to store the current number count elsewhere. If you wanted to use mongo, you could have a doc with commentCount in a different collection & do a findAndUpdate with $inc and use the returned value. This still leads to a weird race condition where a user might only see comments 1 and 3 when comment 2 takes longer to create than comment 3.
I think the approach of storing the comment number on the document is fundamentally flawed: it creates weird race conditions, strange error handling, and complex deletes. If possible, it's better to calculate the number of comments on the way out.
As far as ordering goes, mongo _ids encode date-time information at the start of the _id, so you can use the _id to sort documents.
I wanna confirm the right way to get skip(3) values using minquery, 1. foreach skip, get 1,2,3 page data, then return the 3rd value? or 2. use a way to get the cursor of skip(3). if the 2rd is right, how to get the cursor of skip(3) page? Thanks.
You can't skip documents directly using github.com/icza/minquery. The purpose of minquery is to not have to use Query.Skip() (because that becomes less efficient when the number of "skippable" documents grows). The only way to skip 3 documents is to query for more than 3, and throw away the first 3.
minquery is for cases where you don't have to skip the initial documents. minquery requires you to iterate over the documents, and acquire the cursor that encodes the index entry of the last returned document (this cursor is returned to you by MinQuery.All()). When you need the next page, you have to use the cursor you acquired in the previous query, and then it can list subsequent documents without having to skip anything, because the encoded index entry can be used to jump right where the last query finished listing documents.
Think of GMail: you can always jump just to the next (and previous) page of emails, but you have no way of "magically" jumping to the 10th or 100th page: GMail uses the same mechanism under the hood.
I am confused whether we should create separate API for fetching result and result-count OR we should fetch count based on query string in the result API only.
/api/results/ : Fetches all records
/api/results/?city=1: Fetches all records with city=1
/api/results/?iscount=1: Fetches the count of records i.e. list of cityId and count of record for respective cityId
/api/results/?city=1&iscount=1: Fetch the count of record for cityId=1
OR
/api/resultcount/: Fetches the count of records i.e. list of cityId and count of record for respective cityId
/api/resultcount/?city=1: Fetch the count of record for cityId=1
To me query string is used for filtering of resource so, I am in favor of creating separate API for fetching the counts. Opinion?
We don't need to create another point for fetching the count. Instead, we can send the count details in the response header.
It will be something like below,
/api/results/(GET method) - This will return the results.
/api/results/(HEAD method) - This will just return the results count in the response header.
Please take a look at the following link
I am looking for something like FOUND_ROWS() in mysql select query in algolia results as I need to keep a track of how many total results to expect. Is there someway to get this in Algolia?
The proper way to obtain the number of results is to access the nbHits value which is available in the JSON response of every search call.
I have a posts collection which stores posts related info and author information. This is a nested tree.
Then I have a postrating collection which stores which user has rated a particular post up or down.
When a request is made to get a nested tree for a particular post, I also need to return if the current user has voted, and if yes, up or down on each of the post being returned.
In SQL this would be something like "posts.*, postrating.vote from posts join postrating on postID and postrating.memberID=currentUser".
I know MongoDB does not support joins. What are my options with MongoDB?
use map reduce - performance for a simple query?
in the post document store the ratings - BSON size limit?
Get list of all required posts. Get list of all votes by current user. Loop on posts and if user has voted add that to output?
Is there any other way? Can this be done using aggregation?
NOTE: I started on MongoDB last week.
In MongoDB, the simplest way is probably to handle this with application-side logic and not to try this in a single query. There are many ways to structure your data, but here's one possibility:
user_document = {
name : "User1",
postsIhaveLiked : [ "post1", "post2" ... ]
}
post_document = {
postID : "post1",
content : "my awesome blog post"
}
With this structure, you would first query for the user's user_document. Then, for each post returned, you could check if the post's postID is in that user's "postsIhaveLiked" list.
The main idea with this is that you get your data in two steps, not one. This is different from a join, but based on the same underlying idea of using one key (in this case, the postID) to relate two different pieces of data.
In general, try to avoid using map-reduce for performance reasons. And for this simple use case, aggregation is not what you want.