I am writtng an application in lucene, in which i am retreiving records from db and indexing it. When i search the index, its gives me Lucene's objects in result, but i want it to return collection which contain my own objects, so that it is easy to use.
Say, i indexed the whole book table from db into lucene indexes. Now i am searching the index by author name, i want it to return a collection which contains all Book objects with the desired author.
The normal use case for Lucene would be that the results contain everything that is needed to display a list of search results, but not more than that (in particular not ALL information). In the case of books this might be title, author and ISBN (and maybe a DB ID if that's needed to identify a book uniquely). In most cases not all information is part of the index anyway, in which case you'd need to hit the DB to get the rest of it - and then you might use SQL to perform the search instead of Lucene to begin with.
So I'd say that the Lucene search should return the minimal set of information needed for display, and once a user selects a particular book, the DB can be accessed to retrieve all information about it.
Or do you have in fact ALL information about the book in the index? Then it shouldn't be hard to recreate a Book object from the search results, but then the question becomes: why use a DB for storing the information in the first place, instead of just a Lucene index?
Not sure what you're getting at - how (or why) would indexing multiple tables be different from indexing a single table? Obviously, you'd want the table name in your Document, so that you'll know from which table a query result originates.
The longest recorded flight time of a chicken is 13 seconds. But that was done without this tiny ad: