Ok, this brings me to the question; how are the two view's connected to
each other (since you are indexing partly view 1 and partly view 2 into a
single index structure?
If they are not at all connected I believe you have made a fundamental
mistake / misunderstand the use of your index...
I assume that a Task can be assigned to a person, and your Team view
displays that person, right?
Maybe you are doing something like this:
View 1
1, somename, sometimestamp, someothertimestamp
2, someothername, somethirdtimestamp, timetamp4
...
View 2
1, 58, 0
2, 58, 1
3, 52, 0
...
I'm really confused about your database structure...
To me, It would be logical to add a team_id field to the team table, and
add a third table to link tasks to a team (or to individual persons).
Once you have that information (because I do assume there MUST be some
link there) you would do:
insert into your index:
(id from the task), (name of the task), (id of the person assigned to
this task), (id of the departement that this person works in).
I guess that you _might_ be thinking a bit wrong and trying to do
something like this:
Treat each view as independent views, and inserting values from each table
as separate documents in the index
so you would do:
insert into your index:
(id from the task), (name of the task), (no value), (no value) ---- which
will be ok to do
(no value), (no value), (id of the person), (id of the departement) ---
which makes no sense to me...
So, can you clearify the relationship between the two views, and how you
are thinking of inserting entries into your index?
- Aleks
On Fri, 21 Nov 2008 10:33:28 +0100, Raghunandan Rao
<[EMAIL PROTECTED]> wrote:
View structure is:
1.
Task(id* (int), name (string), start (timestamp), end (timestamp))
2.
Team(person_id (int), deptId (int), isManager (int))
* is primary key
In schema.xml I have
<field name="id" type="integer" indexed="true" stored="true"
required="true"/>
<field name="name" type="text" indexed="true" stored="true"/>
<field name="personId" type="integer" indexed="true" stored="true"/>
<field name=" deptId" type="integer" indexed="true" stored="true"/>
<uniqueKey>id</uniqueKey>
-----Original Message-----
From: Aleksander M. Stensby [mailto:[EMAIL PROTECTED]
Sent: Friday, November 21, 2008 2:56 PM
To: solr-user@lucene.apache.org
Subject: Re: Unique id
Hello again. I'm getting a bit confused by your questions, and I believe
it would be easier for us to help you if you could post the field
definitions from your schema.xml and the structure of your two database
views.
ie.
table 1: (id (int), subject (string) -.--)
table 2: (category (string), other fields ..)
So please post this and we can try to help you.
- Aleks
On Fri, 21 Nov 2008 07:49:31 +0100, Raghunandan Rao
<[EMAIL PROTECTED]> wrote:
Thanks Erik.
If I convert that to a string then id field defined in schema.xml
would
fail as I have that as integer. If I change that to string then first
view would fail as it is Integer there. What to do in such scenarios?
Do
I need to define multiple schema.xml or multiple unique key
definitions
in same schema. How does this work? Pls explain.
-----Original Message-----
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 6:40 PM
To: solr-user@lucene.apache.org
Subject: Re: Unique id
I'd suggest aggregating those three columns into a string that can
serve as the Solr uniqueKey field value.
Erik
On Nov 20, 2008, at 1:10 AM, Raghunandan Rao wrote:
Basically, I am working on two views. First one has an ID column. The
second view has no unique ID column. What to do in such situations?
There are 3 other columns where I can make a composite key out of
those.
I have to index these two views now.
-----Original Message-----
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2008 5:24 PM
To: solr-user@lucene.apache.org
Subject: Re: Unique id
Technically, no, a uniqueKey field is NOT required. I've yet to run
into a situation where it made sense not to use one though.
As for indexing database tables - if one of your tables doesn't have
a
primary key, does it have an aggregate unique "key" of some sort? Do
you plan on updating the rows in that table and reindexing them?
Seems like some kind of unique key would make sense for updating
documents.
But yeah, a more detailed description of your table structure and
searching needs would be helpful.
Erik
On Nov 19, 2008, at 5:18 AM, Aleksander M. Stensby wrote:
Yes it is. You need a unique id because the add method works as and
"add or update" method. When adding a document whose ID is already
found in the index, the old document will be deleted and the new
will be added. Are you indexing two tables into the same index? Or
does one entry in the index consist of data from both tables? How
are these linked together without an ID?
- Aleksander
On Wed, 19 Nov 2008 10:42:00 +0100, Raghunandan Rao
<[EMAIL PROTECTED]
wrote:
Hi,
Is the uniqueKey in schema.xml really required?
Reason is, I am indexing two tables and I have id as unique key in
schema.xml but id field is not there in one of the tables and
indexing
fails. Do I really require this unique field for Solr to index it
better
or can I do away with this?
Thanks,
Rahgu
--
Aleksander M. Stensby
Senior software developer
Integrasco A/S
www.integrasco.no
