Ii have a txt file which contains 2000 rows of data. I want to retrive this data and dispaly in a table form, but i want show some 20-30 records per page and rest numbering the pages like in google.
How do you achieve this in jsp.
After reading the article linked by Jon, you can use Displaytag which has built-int paging functionality
You need to look into pagination using JSP, there's a tutorial that I found from this great search engine called Google:
http://www.javaworld.com/javaworld/jw-07-2004/jw-0726-pagination.html
It will talk you through the process.
This question is asked a few several times before here. Just checkout under each the tags pagination + jsp. I've answered this topic: ResultSet to Pagination. You may find it useful as well.
DisplayTag is another alternative, but it is not memory efficient as it caches all the rows in Java's memory, which might blow if you have thousands of rows and/or thousands of concurrent users. In such case better go ahead with DAO/database-level pagination, as outlined in my answer in the linked topic.
Related
I am now working on a web app associated with Amazon DynamoDB,
I want to achieve a function that my users can directly get to the Nth page to view the item info,
I have been told that the pagination in DynamoDB is based on last key, rather than limit/offset.It doesn't natively support offset.DynamoDB Scan / Query Pagination
Does that mean : If I want to get to the 10th page of items, then I have to query the 9 pages ahead first?(which seems reeeeeally not a good solution)
Is there a easier way to do that?
You are right. DynamoDB doesn't support numerical offset. The only way to paginate is to use the LastEvaluatedKey parameter when making a request. You still have some good options to achieve pagination using a number.
Fast Cursor
You can make fast pagination requests by discarding the full result and getting only the Keys. You are limited to 1MB per request. This represents a large amount of Keys! Using this, you can move your cursor to the required position and start reading full objects.
This solution is acceptable for small/medium datasets. You will run into performance and cost issues on large datasets.
Numerical index
You can also create a global secondary index where you will paginate your dataset. You can add for example an offset property to all your objects. You can query this global index directly to get the desired page.
Obviously this only works if you don't use any custom filter... And you have to maintain this value when inserting/deleting/updating objects. So this solution is only good if you have an 'append only' dataset
Cached Cursor
This solution is built on the first one. But instead of fetching keys every single time, you can cache the pages positions and reuse them for other requests. Cache tools like redis or memcached can help you to achieve that.
You check the cache to see if pages are already calculated
If not, you scan your dataset getting only Keys. Then you store the starting Key of each page in your cache.
You request the desired page to fetch full objects
Choose the solution that fits your needs. I hope this will help you :)
I am trying to do jsp pagination, I loooked all over but didnt find any example that shows the way I want to do it. In my program I am loading data from oracle table using package. I have a package that has procedure loaddata, which is called from javabean load function. Curently all the data are dumped to jsp page from javabean, some one has a example I can look at it to change it into multiple pages. Thank you
Where can I find JSP pagination examples?
Quick and simple answer, use this:
http://www.datatables.net/
It's a lovely scrollable/paginating table, which has third party plugins which allow editing. It's pretty easy to setup, and the website has lots of examples and an active and helpful forum.
From a database perspective, you'll need to consider accepting the following parameters to your queries:
Rows per page
Current page
The DBA in my company splits this into two queries I need to call:
Give me all the values for page 1, with 10 rows per page.
Give me the maximum number of pages that are possible (don't actually return any values.)
I am building a set of 'Now-Trending' kind of visualizations to showcase the trending searches/ trending documents within my system. The idea to show the top queries that came to my system/ most viewed results etc.
I was wondering what would be the most effective and scalable Java based backend for this. If it's a database what should be the schema like? Or is it wise to maintain this info within a Lucene index? Presently for the prototype I store them in a flat file in an unstructured format.
You might try storing this kind of data in a key-value store such as Redis. Redis has efficient atomic methods for incrementing counters that you can use for accruing votes for queries.
A schema-less backend might be preferable if you plan on capturing data ad-hoc or are unsure of your data needs in the future. Additionally, a scalable solution (horizontally) would support growth in the dataset. With regards to your question about whether to store this data in a search engine, here's a great article going over that concept with some examples.
http://www.elasticsearch.org/blog/2011/05/13/data-visualization-with-elasticsearch-and-protovis.html
I am developing a search component of a web application using Lucene. I would like to save the user queries to an index and use them to suggest alternate queries to users, and to keep query statistics (most often used queries, top scoring queries, ...).
To use this data for alternate query suggestions, I would analyze the queries to see which terms are most often used with one another and use that to create a suggestion to the user.
But I can't figure out in which form to index the data. I was thinking of simply adding the queries into the index, but in that way there could be a lot of redundant data since many documents in the index would have the same content. Does anyone have any ideas about the way this can be accomplished?
Thanks for the help.
"I was thinking of simply adding the queries into the index, but in that way there could be a lot of redundant data since many documents in the index would have the same content"
You can tell Lucene not to store document content, which means that the principal overhead will be the unique Terms, and the index itself. So, it might not be a large overhead to store each query as a unique Document...this way you will not be throwing away any information.
First, I believe that you should store the queries separately from the existing index. The problem is not redundant data but rather "watering down" your index - storing the queries in the same index may harm the relevance of your searches. Some options for this are:
Use a separate Lucene index.
Use Solr, with two separate cores, one for the documents and the other for the queries.
Use a query log. Store scores with the queries. Build query statistics using post-processing.As this is a web application, you can probably use a servlet container, such as Tomcat's, logs for this.
Second, Auto-Suggest From Popular Queries Using EdgeNGrams suggests an alternative implementation of query suggestion using Solr.
Our website needs to give out data to the world. This is open-source data that we have stored, and we want it to make it publicly available. It's about 2 million records.
We've implemented the search of these records using Lucene, which is fine, however we'd like to show an individual record (say the user clicks on it after the search is done) and provide more detailed information for that record.
This more detailed information however isn't stored in the index directly... there are like many-to-many relationships and we use our relational database (MySQL) to provide this information.
So like a single record belongs to a category, we want the user to click on that category and show the rest of the records within that category (lots more associations like this).
My question is, should we use Lucene also to store this sort of information and retrieve it through simple search (category:apples), or should MySQL continue doing this logical job? Should I use Lucene only for the search part?
EDIT
I would like to point out that all of our records are pretty static.... changes are made to this data once every week or so.
Lucene's strength lies in rapidly building an index of a set of documents and allowing you to search over them. If this "detailed information" does not need to be indexed or searched over, then don't store it in Lucene.
Lucene is not a database, it's an index.
You want to use Lucene to store data?, I thing it's ok, I've used Solr http://lucene.apache.org/solr/
which built on top of Lucene to work as search engine and store more data relate to the record that maybe use for front end display. It worked with 500k records for me, and 2mil records I think it should be fine.