It sounds good not to use more than one core, for sure I do not want to over complicate this.
Yes I meant tables. It's pretty simple. Both table courses and languages has it's own primary key courseseqno and languagesseqno Both also have a foreign key "userid" that references the users table with column userid The relationship from users to courses and languages are one-to-many. but I guess I'm thinking wrong because my idead whould be to have a "block" of fields connected with one id <field name="coursename" type="string" indexed="true" /> <field name="startdate" type="date" indexed="true" /> <field name="enddate" type="" indexed="true" /> These three are connected with a <field name="courseseqno" type="int" indexed="true" /> But also have a <field name="userid" type="int" indexed="true" /> To connect to a specific user? Thanks /Niklas -----Ursprungligt meddelande----- Från: Gora Mohanty [mailto:g...@mimirtech.com] Skickat: den 11 januari 2013 15:55 Till: solr-user@lucene.apache.org Ämne: Re: configuring schema to match database On 11 January 2013 19:57, Niklas Langvig <niklas.lang...@globesoft.com> wrote: > Ahh sorry, > Now I understand, > Ok seems like a good solution, I just know need to understand how to > query multiple cores now :) There is no need to use multiple cores in your setup. Going back to your original problem statement, it can easily be handled with a single core, and it actually makes more sense to do it that way. You will need to give us more details. >> > My question should be really easy, it has most likely been asked >> > many times but still I'm not able to google any answer to it. >> > >> > To make it easy, I have 3 columns: users, courses and languages Presumably, you mean three tables, as you describe each as having columns. How are the tables connected? Is there a foreign key relationship between them? Is the relationship one-to-one, one-to-many, or what? >> > Users has columns , userid, firstname, lastname Courses has column >> > coursename, startdate, enddate Languages has column language, >> > writingskill, verbalskill [...] >> > I would like to put this data into solr so I can search for all >> > "users how have taken courseA and are fluent in english". >> > Can I do that? 1. Your schema for the single core is quite straightforward, and along the lines of what you had described (one field for each database column in each table), e.g., <field name="userid" type="string" indexed="true" /> <field name="firstname" type="string" indexed="true" /> <field name="lastname" type="string" indexed="true" /> <field name="coursename" type="string" indexed="true" /> <field name="startdate" type="date" indexed="true" /> <field name="enddate" type="" indexed="true" /> <field name="language" type="string" indexed="true" /> <field name="writingskill" type="string" indexed="true" /> <field name="verbalskill" type="string" indexed="true" /> Pay attention to the type. Dates should typically be solr.DateField. The others can be strings, but if they are integers in the database, you might benefit from making these integers in Solr also. 2. One has to stop thinking of Solr as a RDBMS. Instead, one flattens out data from a typical RDBMS structure. It is difficult to give you complete instructions unless you describe the database relationships, but, e.g., if one has userA with course1, course2, and course3, and userB with course2, course4, the Solr documents would be : <userA> <course1> <details for course1...> <userA> <course2> <details for course2...> <userA> <course3> <details for course3...> <userB> <course2> <details for course2...> <userB> <course4> <details for course4...> This scheme could also be extended to languages, depending on how the tables are related. 3. While indexing into Solr, one has to select from the database, and flatten out the data as above. The two main ways of doing this are using a library like SolrJ for Java (other languages have other libraries, e.g., django-haystack is easy to get started with if one is using Python/Django), or the Solr DataImportHandler (please see http://wiki.apache.org/solr/DataImportHandler ) with nested entities. 4. With such a structure, querying Solr should be simple. Regards, Gora
