I have a view in a very basic Drupal site -- its basic purpose is to collect data, not display it in any fancy way -- that will only show 999 items. I'm not referring to paging; I'm referring to the total number of items listed by the time you get to the last page, regardless of pagination size. I have looked at every item in the content type definition and the view and can't find anything that would cause this. I know it would be very weird, but is there some limit on the total number of items a Drupal view can handle? Is there some LIMIT 1000 clause attached to a SQL query somewhere?
Never mind people -- the problem is that the field is a text field, and not numeric (as it should be), so the items are being sorted aphabetically and not as numbers. Oops.
Related
In Wordpress, every post (entry, product, etc) has a unique ID number. As the sites grow up in content, I've realized that the ID numbers are increasing constantly.
I'm guessing that the number of posts available can be quite high (or so I hope!) but I'm asking out of curiosity. Is there actual limit of posts you can have?
What happens when a post is deleted? Do the system fill up the gaps in some way?
Is it OK to leave the posts there to grow old like the wine or is it a good practice to clean up every now and then if you have too many?
The wp_post.ID column is a unsigned bigint, which (in MySQL, the database used by Wordpress) can store values from 0 to 18446744073709551615 ((2^64)-1). So in theory, that is the maximum number of posts.
Now, there are other tables that get multiple rows for each post and those tables have the same maximum (because their ID column is also a unsigned bigint). For example "posts meta" and comments. Because of that, you'll run into problems a bit sooner, but even if posts_meta gets 1000 rows for each post, you'll still have about 1844674407370955 posts you can make before you run into this limit.
Now, the question wasn't "is there a maximum amount of posts", the question is "is it possible to run out of IDs". I would call creating 1844674407370955 posts impossible, so: no.
Just implemented "startAfter" for the first time. However, a bit of searching around and I cannot find an answer to an issue I have.
How best to handle when there are no more documents to load when using "start after".
Should I grab the collections total document length each time I fire a "load more" function. Check total vs current and if they are equal, disable the load more function?
If so, how do I find the total count of the collections documents?
Should I grab the collections total document length each time I fire a "load more" function.
No. When we create a pagination algorithm, we are always interested to load data in smaller chunks. In Firestore, we are always also interested in the size of each new chunk that we get. So basically, if the new chunk has the size that is smaller than the limit we have set, for example, 10 items per page, then that's the moment when you should disable "load more function".
So the idea is that you can request pages of data of a certain size. Here's a helpful method named limit(X) that can help you achieve this. So you can perform a query and get a page of size X. Simply continue that query with another page of size X, and so on. So you start on page 1, then progress through the pages using the corresponding methods where you should specify which document was the last one on the page and then continue to get the next page until there are no elements left.
If so, how do I find the total count of the collections documents?
Isn't about the number of documents in a collection that you have to worry it's about the number of the items you get in the next page.
What you can do is save the last visible document to a variable, like so
lastVisible = querySnapshot.docs[querySnapshot.docs.length - 1]
In the Project Tracker template there is a feature where statistics for a certain project's items are displayed. You can filter the project items, but the statistics will only show those statistics for all the project items, i.e. the filters do not affect the statistics.
I would like to add the feature of filters affecting those statistics in a similar implementation of mine. My current solution passes the keys of those project items (affected by filters, too) to a calculated data source, which then calculates the statistics using those item keys, essentially applying the filters used in the page.
My issue is that my calculations are restricted by the query page size. For example, if I apply filters that limit the number of items to 15 records, but the page size is 10 records, I will only have statistics of those first 10 items, which is not useful. I'd need to have the statistics on all the records that are left after filtering.
One way to solve this would be to get rid of the query page size and leave it at 0. However, similarly to the Project Tracker template, I'm displaying the project items on the page in a table, and if I do that, the page becomes too heavy.
How can I circumvent the query page size? I'm thinking I could
limit the items displayed in the page by some other way than query page size (i.e. hiding items from the UI)
use a different datasource for the statistics, but in some way copying the filters used in the datasource that is displaying the project items
Both of these ways I could think of, I can't seem to implement. I don't know how I could hide items from the UI to make it less heavy, as query page size pretty much does it. I have also tried copying the filters from a datasource to a similar one, but that does not seem to work.
EDIT: I might have come up with a way to solve this myself, but I still need to implement it. Now I'm using the page size restricted Items Ds to apply the filters on, and the statistics are build from this data source. If instead, I use a non-restricted Ds called AllItems, and apply the filters on it, and then pass the item keys to a page size restricted Ds (to show the items in UI) AND to a calculated Ds (for the stats). Will make a response once I've verified it works.
I solved the issue myself.
To produce (refreshable) statistics subject to filtering but not restricted by page size, I used the following datasource structure:
In this structure, the filters practically flow to the data sources below, as they are passed the ItemKeys that fit the filter. What this completes is that my Statistics (used in piegraphs etc.) can be filtered dynamically and account for all the records that fit the filter, while the UI does not get crowded over too many records, as the data source used in UI has a query page size limitation.
Is there a way to automatically set a weight to nodes in Drupal? I am wanting to achieve this, because I am creating a blog layout and I want the most recent articles to appear on the top of my secondary menu rather than on the bottom.
By trying to sort by a dynamically iterating weight field, you're adding complexity to something that is really quite straight forward. This scenario is best handled by sorting by the created, or updated date of the node. I mean, by definition, that will allow you to sort by the most recent article. Heck, even sorting by the node ID would be better, since you have a value that's automatically increasing for every item that's created.
A weight field should only be used when sorting needs to be empirical, like a todo list or something. If you're using a weight field because you want to adjust the sorting of an article later on, you would still get the desired result by sorting by multiple columns (i.e. weight ASC, created DESC).
Before I explain the problem, let me set the context. I have a stored procedure which returns me paged results. So if I mentioned the page number as 1, I get the first 10 records and if the page number is 2 I get the next 10 set of records and so on.
Now in my Asp.Net page I need to show 10 items at a time and I want the pagination to be in numbered style. The same like Google pagination.
The problem now is that, since I get only 10 records at a time from the DB, the numbers don't show up. I've come across a solution at: How to use DataPager with Database Paged, however since my total number of records can run into 100's or 1000's, running the loop for so long is again a performance issue.
It would be great if you can let me know how this issue can be fixed.
Thanks in advance.
Tweak your stored procedure to add an output parameter that returns the total number of records that will be returned without pagination. You can then use that number to create your pager controls.