Dear Wiki user, You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.
The following page has been changed by NoblePaul: http://wiki.apache.org/solr/DataImportHandler ------------------------------------------------------------------------------ == Configuration in data-config.xml == A SOLR document can be considered as a de-normalized schema having fields whose values come from multiple tables. - The data-config.xml starts by defining a "document" element which contains '''one root entity'''. The root entity can contain multiple sub-entities. An entity corresponds to a table in a relational database. Each entity can contain multiple fields. Each field can correspond to a column in it's parent's table. Alternately, a field can also be a copyField which can get data from multiple columns. For each field, write only the column name from which the value for this field should come. If the column name is different from the field name, then another attribute ''name'' should be given. Rest of the required attributes such as ''type'' will be read directly from the SOLR schema.xml. + The data-config.xml starts by defining a "document" element A `document` has a 1:1 relationship with a core and the ''name'' attribute of the tag refers to the ''core name' (Ignore this for single core deployments). A document contains '''one and only oneroot entity'''. The root entity can contain multiple sub-entities which in turn can contain other entities. An entity is a table/view in a relational database . Each entity can contain multiple fields. Each field corresponds to a column in the resultset returned by the ''query'' in the entity .For each field, mention the column name in the resultset. If the column name is different from the solr field name, then another attribute ''name'' should be given. Rest of the required attributes such as ''type'' will be read directly from the SOLR schema.xml. - In order to get data from the database, our design philosophy revolves around templatized 'sql' entered by the user for each entity. This gives the user the entire power of SQL if he needs it. The root entity is the central table whose primary key can be used to join this table with other child entities. + In order to get data from the database, our design philosophy revolves around 'templatized sql' entered by the user for each entity. This gives the user the entire power of SQL if he needs it. The root entity is the central table whose primary key can be used to join this table with other child entities. Let us consider an example. Suppose we have the following schema in our database
