s.
>
> How does one call the commit method anyway? Isn't it automatically called?
>
> Jim.
>
> Joseph Ottinger wrote:
>
> >I've had success with deletion by running IndexReader.delete(int), then
> >getting an IndexWriter and optimizing the directory. I do
I've had success with deletion by running IndexReader.delete(int), then
getting an IndexWriter and optimizing the directory. I don't know if
that's "the right way" to do it or not.
On Tue, 1 Feb 2005, Jim Lynch wrote:
> I've been merrily cooking along, thinking I was replacing documents when
> I
https://lucenerar.dev.java.net
LuceneRAR is now working on two containers, verified: The J2EE 1.4 RI and
Orion. Websphere testing is underway, with JBoss to follow.
LuceneRAR is a resource adapter for Lucene, allowing J2EE components to
look up an entry in a JNDI tree, using that reference to add
First off, Erik, thank you for taking an interest in any way. As I've said
before, I'm not trying to represent myelf as a Lucene expert, so having
someone point out flaws is god.
On Wed, 19 Jan 2005, Erik Hatcher wrote:
> >> Could you elaborate on some use cases?
> >
> > Sure, and I'll pic
On Wed, 19 Jan 2005, Erik Hatcher wrote:
> On Jan 19, 2005, at 2:27 PM, Joseph Ottinger wrote:
> > After babbling endlessly about an RDMS directory and my lack of success
> > with it, I've created a project on java.net to create a Lucene JCA
> > component, to allow J
After babbling endlessly about an RDMS directory and my lack of success
with it, I've created a project on java.net to create a Lucene JCA
component, to allow J2EE components to interact with a Lucene service.
It's at https://lucenerar.dev.java.net/ currently.
It's very crude. In current form, in
I just realised that the Hits object isn't Serializable, although Document
and Field are. I can easily build a Hits equivalent that *is*
Serializable, but should that be on my end, or at the Lucene API level?
---
Joseph B. Ottinge
On Wed, 12 Jan 2005, Morus Walter wrote:
> Joseph Ottinger writes:
> >
> > According to IndexWriter.java, line 246 (in 1.4.3's codebase), if closeDir
> > is set, it's supposed to close the directory. That's fine - but that leads
> > me to believe t
*sigh* Yet again, I apologize. I'm generating altogether too much traffic
here lately!
I'm stuck. I have a custom Directory, and I *need* a callback point so I
can clean up. There's a method for this: Directory.close(), which I've
overridden.
It never gets called!
According to IndexWriter.java,
On Tue, 11 Jan 2005, Doug Cutting wrote:
> Joseph Ottinger wrote:
> > As one for whom the question's come up recently, I'd say that locks need
> > to be terminated gracefully, instead. I've noticed a number of cases where
> > the locks get abandoned in exc
On Tue, 11 Jan 2005, Chris Hostetter wrote:
> 2) it might be a good idea to add a static utility method for cleanly
> removing all locks (or all lokcs of a particular type) on an index given a
> Directory. Javadocs would indicate this is an "Expert" method which
> should only be used in code desi
Gosh, I'm really sorry for the number of posts I'm making.
Again, to recap; I'm writing a Directory, a SQL-based one.
>From what I can tell, in IndexWriter, my directory's close method is never
getting called. I don't know why, because the calling code calls
IndexWriter.close, and with the constr
On Mon, 10 Jan 2005, Erik Hatcher wrote:
> On Jan 10, 2005, at 8:26 AM, Joseph Ottinger wrote:
> > With a file-based directory, that works well enough - and I realise
> > there
> > might be a better way to do it (but I don't know it yet.)
>
> How about using I
I'm still working through making my own directory, based on JDBC (and yes,
I know, there are some out there already, unsuitable for this reason or
that reason.)
One thing I've noticed is that the Lock procedure in IndexWriter is a
little off, I think.
My normal process on application startup is t
On Thu, 6 Jan 2005, Erik Hatcher wrote:
>
> On Jan 6, 2005, at 10:41 AM, Joseph Ottinger wrote:
> > SHouldn't Lucene warn the user if they do something like this?
>
> When a user indexes a null? Or attempts to write to the index from two
> different IndexWriter in
hough.
SHouldn't Lucene warn the user if they do something like this?
On Thu, 6 Jan 2005, Erik Hatcher wrote:
> Do you have two threads simultaneously either writing or deleting from
> the index?
>
> Erik
>
> On Jan 6, 2005, at 9:27 AM, Joseph Ottinger wrote:
>
> > Sor
fired
through looks for a lock and finds one, when I would think it wouldn't be
there.
What am I not understanding?
On Thu, 6 Jan 2005, Joseph Ottinger wrote:
> If this is a stupid question, I deeply apologize. I'm stumped.
>
> I have a message-driven EJB using Lucene. In *every*
If this is a stupid question, I deeply apologize. I'm stumped.
I have a message-driven EJB using Lucene. In *every* case where the MDB is
trying to create an index, I'm getting "Lock obtain timed out."
It's in org.apache.lucene.store.Lock.obtain(Lock.java:58), which the user
list has referred to
I pronounce it "lieu'-seen" or "loo'-seen", usually the latter because I'm
lazy.
On Mon, 11 Aug 2003, Danny Sofer wrote:
> ...and where does the name come from?
>
> we've already developed three way to say 'lucene' and we can't agree on
> which one we like best.
>
> somebody please help!
>
> many
u for your time.
On Wed, 5 Mar 2003, Doug Cutting wrote:
> Joseph Ottinger wrote:
> > Then this means that my IndexReader.delete(i) isn't working properly. What
> > would be the common causes for this? My log shows the documents being
> > deleted, so something's
Okay, I think I've done something stupid here: on closer examination, it
looks like my comparison to find the specific documents to delete is
failing. Let me look further at that.
On Wed, 5 Mar 2003, Doug Cutting wrote:
> Joseph Ottinger wrote:
> > Then this means that my IndexR
Then this means that my IndexReader.delete(i) isn't working properly. What
would be the common causes for this? My log shows the documents being
deleted, so something's going wrong at that point.
On Wed, 5 Mar 2003, Doug Cutting wrote:
> Joseph Ottinger wrote:
> > This sh
I've got a versioning content system where I want to replace documents in
a lucene repository. To do so, according to the FAQ and the mailing list
archives, I need to open an IndexReader, look for the document in
question, delete it via the IndexReader, and then add it.
This shouldn't replace the
23 matches
Mail list logo
