But do note that there's also no requirement that all documents have the same fields. So you could consider storing a special "meta document" that had *no* fields in common with any other document that records whatever information you want about the current state of the index.
Best Erick On Wed, Jan 28, 2009 at 5:15 PM, Otis Gospodnetic < otis_gospodne...@yahoo.com> wrote: > There is no existing internal field like that. > > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > ----- Original Message ---- > > From: Ian Connor <ian.con...@gmail.com> > > To: solr-user@lucene.apache.org > > Sent: Wednesday, January 28, 2009 4:59:28 PM > > Subject: Re: solr as the data store > > > > I am planning with backups, the recovery will only be incremental. > > > > Is there an internal field to know when the last document hit the index > or > > is this best to build your own "created_at" type field to know when you > need > > to rebuild from? > > > > After the backup is restored, this field could be read and then the > restore > > from that time could kick in. > > > > On Wed, Jan 28, 2009 at 4:34 PM, Feak, Todd wrote: > > > > > Although the idea that you will need to rebuild from scratch is > > > unlikely, you might want to fully understand the cost of recovery if > you > > > *do* have to. > > > > > > If it's incredibly expensive(time or money), you need to keep that in > > > mind. > > > > > > -Todd > > > > > > > > > -----Original Message----- > > > From: Ian Connor [mailto:ian.con...@gmail.com] > > > Sent: Wednesday, January 28, 2009 12:38 PM > > > To: solr > > > Subject: solr as the data store > > > > > > Hi All, > > > > > > Is anyone using Solr (and thus the lucene index) as there database > > > store. > > > > > > Up to now, we have been using a database to build Solr from. However, > > > given > > > that lucene already keeps the stored data intact, and that rebuilding > > > from > > > solr to solr can be very fast, the need for the separate database does > > > not > > > seem so necessary. > > > > > > It seems totally possible to maintain just the solr shards and treat > > > them as > > > the database (backups, redundancy, etc are already built right in). The > > > idea > > > that we would need to rebuild from scratch seems unlikely and the speed > > > boost by using solr shards for data massaging and reindexing seems very > > > appealing. > > > > > > Has anyone else thought about this or done this and ran into problems > > > that > > > caused them to go back to a seperate database model? Is there a > critical > > > need you can think is missing? > > > > > > -- > > > Regards, > > > > > > Ian Connor > > > > > > > > > > > -- > > Regards, > > > > Ian Connor > > 1 Leighton St #723 > > Cambridge, MA 02141 > > Call Center Phone: +1 (714) 239 3875 (24 hrs) > > Fax: +1(770) 818 5697 > > Skype: ian.connor > >
