Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of gui@prosoma.com.br designates
 67.19.26.18 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <c0c0e1d40709031034j528c27f8he4d3d3d9493e552a@mail.gmail.com>
References: <F80C0536-F2FB-46D6-9BB2-5C2C2909F7D8@prosoma.com.br>
 <c0c0e1d40709030650u6b736c7bgc1409270f6799c43@mail.gmail.com>
 <F3E0FFE5-BD0F-41D5-88C2-C73F57B79FB8@prosoma.com.br>
 <c0c0e1d40709031034j528c27f8he4d3d3d9493e552a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <A4981700-4522-4E09-822C-BCD49CED72A9@prosoma.com.br>
Content-Transfer-Encoding: quoted-printable
From: Guilherme Barile <gui@prosoma.com.br>
Subject: Re: JdbcDirectory
Date: Mon, 3 Sep 2007 15:47:06 -0300
To: java-user@lucene.apache.org

Storing the data in the index, mainly for non-structured data.
We plan to implement something like this ThingDB from http://=20
demo.openlibrary.org/about/tech, and though that maybe lucene + =20
JdbcDirectory could act as a backend.

gui

On Sep 3, 2007, at 2:34 PM, Askar Zaidi wrote:

> Yes. Every time a user updates a piece of information, you do the =20
> update in
> the DB as well as the Index. If you are using Hibernate, they have =20
> an API
> that does this mapping. I am not sure why you plan to store data in =20=

> the
> Index ?? Storing data is the DBs job, searching is the Index job. I =20=

> would
> suggest you have both (a schema for your data and an index). Thats =20
> what I
> did. I could have stored everything on the Lucene Index, but I am =20
> scared as
> the application grows I will need a DB system eventually. I don't =20
> think
> people use Lucene to "store" data just as they do it in a DBMS.
>
> -
> Askar
>
> On 9/3/07, Guilherme Barile <gui@prosoma.com.br> wrote:
>>
>>> 1) I don't understand why the index would get corrupted. We store
>>> huge data
>>> and meta-data using Lucene.
>>
>> I got that information when lucene 1.4 was the lastest version, may
>> have changed. I'll trust you.
>>
>>> 2) For this, I synced Lucene with the DB operations. If you use
>>> Hibernate,
>>> theres an API for that. Or, you could just write your own factory
>>> methods to
>>> add/delete/edit index documents when a DB operation takes place
>>> (e.g edit).
>>
>> You mean every time you update the db, you update the index also ?
>> I'm actually planning not to use any external entity, and rely
>> everything on Lucene. Wondered if some simple query (get the lastest
>> document for example) would solve the versioning issue
>>
>> Thanks a lot
>>
>> Gui
>>
>>>
>>> On 9/3/07, Guilherme Barile <gui@prosoma.com.br> wrote:
>>>>
>>>> Hello,
>>>>         We're starting a new project, which basically catalogs
>>>> everything
>>>> we
>>>> have in the department (different objects with different metadata),
>>>> and as I used Lucene before, I'm preparing a presentation to the
>>>> team, as I think it would really simplify the storage of =20
>>>> metadata and
>>>> documents.
>>>>         The system will be pretty straightforward, all items =20
>>>> will be
>>>> cataloged,  and most of them won't be changed too much ( I'll raise
>>>> this question later ).
>>>>         So, here are my main concerns, hope you can help
>>>>
>>>> 1) Storing all data (index and content) wasn't recommended in the
>>>> past, as the index could become corrupted. Do I have this =20
>>>> problem if
>>>> I use a JdbcDirectory (PostgreSQL backend) ? I already read =20
>>>> about the
>>>> performance degradation when using a database as main storage, but
>>>> this won't be a problem.
>>>>
>>>> 2) Lucene doesn't support incremental editing (a new Document =20
>>>> will be
>>>> created when someone edits an item), so is it possible to manage =20=

>>>> some
>>>> kind of versioning ? Anyone ever implemented something this way ?
>>>>
>>>> Thanks a lot for the attention
>>>>
>>>> Guilherme Barile
>>>> Prosoma Inform=E1tica
>>>> -------------------------------------------------------------------=20=

>>>> --
>>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org