Data Import Handler – import from Solr XML files

Marek Rogoziński General , , , 0 Comment

So far, in previous articles, we looked at the import data from SQL databases. Today it’s time to import from XML files.

Example

Lets look at the following example: 

<dataConfig>
  <dataSource type="FileDataSource" />
  <document>
    <entity
      name="document"
      processor="FileListEntityProcessor"
      baseDir="/home/import/data/2011-06-27"
      fileName=".*\.xml

Explanation of the example


In comparison with the examples from the earlier articles a new type appeared - the FileDataSource. Example of a complete call:



<dataSource
  type="FileDataSource"
  basePath="/home/import/input"
  encoding="utf-8"/>


The additional, not mandatory attributes are obvious:


    

  • basePath – the directory which will be used to calculate the relative path of the "entity" tag
    • 

  • encoding – the file encoding (default: the OS default encoding)
    • 



After the source definition, we have document definition with two nested entities.


The purpose of the main entity is to generate the files list. To do that, we use the FileListEntityProcessor.This entity is self-supporting and doesn't need any data source (thus dataSource="null"). The used attributes:


    

  • fileName (mandatory) – regular expression that says which files to choose
    • 

  • recursive – should subdirectories be checked  (default: no)
    • 

  • rootEntity – says about if the data from the entity should be treated as documents source. Because we don't want to index files list, which this entity provides, we need to set this attribute to false. After setting this attribute to false the next entity will be treated as main entity and its data will be indexed.
    • 

  • baseDir (mandatory) - the directory where the files should be located
    • 

  • dataSource – in this case we set this parameter to "null" because the entity doesn't use data source  (we can ommit this parameter in Solr > 1.3)
    • 

  • excludes – regular expression which says which files to exclude from indexing
    • 

  • newerThan – says, that only files newer that the parameter value will be taken into consideration. This parameter can take a value in the format: YYYY-MM-dd HH:mm:ss or a single quoted string, like: 'NOW – 7DAYS' or an variable that contains the data, for example: ${variable}
    • 

  • olderThan – the same as above, but says about older files
    • 

  • biggerThan – only files bigger than the value of the parameter will be taken into consideration
    • 

  • smallerThan –only files smaller than the value of this parameter will be taken into consideration
    • 



If you already have a list of files we can go further, the inner entity - its task is to download specific data contained in the files. The data is taken from the file specified by an external entity using a data source. The processor type: XpathEntityProcessor used for XML files have the following attributes:


    

  • url – the input data
    • 

  • useSolrAddSchema – information, that the input data is in Solr XML format
    • 

  • stream – should we use stream for document processing. In case of large XML files, it's good to use stream="true" which will  use far less memory and won't try to load the whole XML file into the memory.
    • 



Additional parameters are not useful in our case and we describe them on another occasion:)


But why all this?


The example allows to read all XML files from the selected directory. We used exactly the same file format as the "classical" method of sending documents to Solr using HTTP POST. So why use this method?


Push and Pull


The first argument can be the control of the connections between the Solr server and the system that is responsible for generating the files that are going to be indexed. When we do not have full control over the data source, it's better to retrieve the data from the source than to provide additional services that could potentially become a target of attack.


Prototyping and change testing


How does it work in practice? In my case I decided to add the possibility of a more advanced search and an ability to do faceting on the category tree. The document contained the "category" field, where it stored the path such as "Cars / Four sits / Audi". To create a new queries, we should have an additional fields in the index that hold the category name, the level of the category and also how many levels we have.


To add the required fields we used the ability to define scripts. Quoted previously imported file now looks like this:



<dataConfig>
  <script><![CDATA[
    function CategoryPieces(row) {
      var pieces = row.get('category').split('/');
      var arr = new Array();
      for (var i=0; i < pieces.length; i++) {
        row.put('category_level_' + i, pieces[i].trim());
        arr[i] = pieces[i].trim();
      }
      row.put('category_level_max', (pieces.length - 1).toFixed());
      row.put('category', arr.join('/'));
      return row;
  }
  ]]></script>
  <dataSource type="FileDataSource" />
  <document>
    <entity
      name="document"
      processor="FileListEntityProcessor"
      baseDir="/home/import/data/2011-06-27"
      fileName=".*\.xml

Note at the end


When using DIH we need to be aware that it works a little differently. In particular, the attempt to load multiple values ​​to a field that is not multivalued (in the schema.xml file) in DIH succeeds - the excess value will be ignored. In the case of "classical" indexing method Solr will return an error.

"
      recursive="false"
      rootEntity="false"
      dataSource="null">
      <entity
        processor="XPathEntityProcessor"
        url="

Explanation of the example


In comparison with the examples from the earlier articles a new type appeared - the FileDataSource. Example of a complete call:





The additional, not mandatory attributes are obvious:


    

  • basePath – the directory which will be used to calculate the relative path of the "entity" tag
    • 

  • encoding – the file encoding (default: the OS default encoding)
    • 



After the source definition, we have document definition with two nested entities.


The purpose of the main entity is to generate the files list. To do that, we use the FileListEntityProcessor.This entity is self-supporting and doesn't need any data source (thus dataSource="null"). The used attributes:


    

  • fileName (mandatory) – regular expression that says which files to choose
    • 

  • recursive – should subdirectories be checked  (default: no)
    • 

  • rootEntity – says about if the data from the entity should be treated as documents source. Because we don't want to index files list, which this entity provides, we need to set this attribute to false. After setting this attribute to false the next entity will be treated as main entity and its data will be indexed.
    • 

  • baseDir (mandatory) - the directory where the files should be located
    • 

  • dataSource – in this case we set this parameter to "null" because the entity doesn't use data source  (we can ommit this parameter in Solr > 1.3)
    • 

  • excludes – regular expression which says which files to exclude from indexing
    • 

  • newerThan – says, that only files newer that the parameter value will be taken into consideration. This parameter can take a value in the format: YYYY-MM-dd HH:mm:ss or a single quoted string, like: 'NOW – 7DAYS' or an variable that contains the data, for example: ${variable}
    • 

  • olderThan – the same as above, but says about older files
    • 

  • biggerThan – only files bigger than the value of the parameter will be taken into consideration
    • 

  • smallerThan –only files smaller than the value of this parameter will be taken into consideration
    • 



If you already have a list of files we can go further, the inner entity - its task is to download specific data contained in the files. The data is taken from the file specified by an external entity using a data source. The processor type: XpathEntityProcessor used for XML files have the following attributes:


    

  • url – the input data
    • 

  • useSolrAddSchema – information, that the input data is in Solr XML format
    • 

  • stream – should we use stream for document processing. In case of large XML files, it's good to use stream="true" which will  use far less memory and won't try to load the whole XML file into the memory.
    • 



Additional parameters are not useful in our case and we describe them on another occasion:)


But why all this?


The example allows to read all XML files from the selected directory. We used exactly the same file format as the "classical" method of sending documents to Solr using HTTP POST. So why use this method?


Push and Pull


The first argument can be the control of the connections between the Solr server and the system that is responsible for generating the files that are going to be indexed. When we do not have full control over the data source, it's better to retrieve the data from the source than to provide additional services that could potentially become a target of attack.


Prototyping and change testing


How does it work in practice? In my case I decided to add the possibility of a more advanced search and an ability to do faceting on the category tree. The document contained the "category" field, where it stored the path such as "Cars / Four sits / Audi". To create a new queries, we should have an additional fields in the index that hold the category name, the level of the category and also how many levels we have.


To add the required fields we used the ability to define scripts. Quoted previously imported file now looks like this:





Note at the end


When using DIH we need to be aware that it works a little differently. In particular, the attempt to load multiple values ​​to a field that is not multivalued (in the schema.xml file) in DIH succeeds - the excess value will be ignored. In the case of "classical" indexing method Solr will return an error.


{document.fileAbsolutePath}"

        useSolrAddSchema="true"

        stream="true">

      </entity>

    </entity>

  </document>

</dataConfig>


Explanation of the example


In comparison with the examples from the earlier articles a new type appeared - the FileDataSource. Example of a complete call:





The additional, not mandatory attributes are obvious:


    

  • basePath – the directory which will be used to calculate the relative path of the "entity" tag
    • 

  • encoding – the file encoding (default: the OS default encoding)
    • 



After the source definition, we have document definition with two nested entities.


The purpose of the main entity is to generate the files list. To do that, we use the FileListEntityProcessor.This entity is self-supporting and doesn't need any data source (thus dataSource="null"). The used attributes:


    

  • fileName (mandatory) – regular expression that says which files to choose
    • 

  • recursive – should subdirectories be checked  (default: no)
    • 

  • rootEntity – says about if the data from the entity should be treated as documents source. Because we don't want to index files list, which this entity provides, we need to set this attribute to false. After setting this attribute to false the next entity will be treated as main entity and its data will be indexed.
    • 

  • baseDir (mandatory) - the directory where the files should be located
    • 

  • dataSource – in this case we set this parameter to "null" because the entity doesn't use data source  (we can ommit this parameter in Solr > 1.3)
    • 

  • excludes – regular expression which says which files to exclude from indexing
    • 

  • newerThan – says, that only files newer that the parameter value will be taken into consideration. This parameter can take a value in the format: YYYY-MM-dd HH:mm:ss or a single quoted string, like: 'NOW – 7DAYS' or an variable that contains the data, for example: ${variable}
    • 

  • olderThan – the same as above, but says about older files
    • 

  • biggerThan – only files bigger than the value of the parameter will be taken into consideration
    • 

  • smallerThan –only files smaller than the value of this parameter will be taken into consideration
    • 



If you already have a list of files we can go further, the inner entity - its task is to download specific data contained in the files. The data is taken from the file specified by an external entity using a data source. The processor type: XpathEntityProcessor used for XML files have the following attributes:


    

  • url – the input data
    • 

  • useSolrAddSchema – information, that the input data is in Solr XML format
    • 

  • stream – should we use stream for document processing. In case of large XML files, it's good to use stream="true" which will  use far less memory and won't try to load the whole XML file into the memory.
    • 



Additional parameters are not useful in our case and we describe them on another occasion:)


But why all this?


The example allows to read all XML files from the selected directory. We used exactly the same file format as the "classical" method of sending documents to Solr using HTTP POST. So why use this method?


Push and Pull


The first argument can be the control of the connections between the Solr server and the system that is responsible for generating the files that are going to be indexed. When we do not have full control over the data source, it's better to retrieve the data from the source than to provide additional services that could potentially become a target of attack.


Prototyping and change testing


How does it work in practice? In my case I decided to add the possibility of a more advanced search and an ability to do faceting on the category tree. The document contained the "category" field, where it stored the path such as "Cars / Four sits / Audi". To create a new queries, we should have an additional fields in the index that hold the category name, the level of the category and also how many levels we have.


To add the required fields we used the ability to define scripts. Quoted previously imported file now looks like this:





Note at the end


When using DIH we need to be aware that it works a little differently. In particular, the attempt to load multiple values ​​to a field that is not multivalued (in the schema.xml file) in DIH succeeds - the excess value will be ignored. In the case of "classical" indexing method Solr will return an error.


"

      recursive="false"

      rootEntity="false"

      dataSource="null">

      <entity

        processor="XPathEntityProcessor"

        transformer=”script:CategoryPieces”

        url="


Note at the end


When using DIH we need to be aware that it works a little differently. In particular, the attempt to load multiple values ​​to a field that is not multivalued (in the schema.xml file) in DIH succeeds - the excess value will be ignored. In the case of "classical" indexing method Solr will return an error.


"

      recursive="false"

      rootEntity="false"

      dataSource="null">

      <entity

        processor="XPathEntityProcessor"

        url="


Explanation of the example


In comparison with the examples from the earlier articles a new type appeared - the FileDataSource. Example of a complete call:





The additional, not mandatory attributes are obvious:


    

  • basePath – the directory which will be used to calculate the relative path of the "entity" tag
    • 

  • encoding – the file encoding (default: the OS default encoding)
    • 



After the source definition, we have document definition with two nested entities.


The purpose of the main entity is to generate the files list. To do that, we use the FileListEntityProcessor.This entity is self-supporting and doesn't need any data source (thus dataSource="null"). The used attributes:


    

  • fileName (mandatory) – regular expression that says which files to choose
    • 

  • recursive – should subdirectories be checked  (default: no)
    • 

  • rootEntity – says about if the data from the entity should be treated as documents source. Because we don't want to index files list, which this entity provides, we need to set this attribute to false. After setting this attribute to false the next entity will be treated as main entity and its data will be indexed.
    • 

  • baseDir (mandatory) - the directory where the files should be located
    • 

  • dataSource – in this case we set this parameter to "null" because the entity doesn't use data source  (we can ommit this parameter in Solr > 1.3)
    • 

  • excludes – regular expression which says which files to exclude from indexing
    • 

  • newerThan – says, that only files newer that the parameter value will be taken into consideration. This parameter can take a value in the format: YYYY-MM-dd HH:mm:ss or a single quoted string, like: 'NOW – 7DAYS' or an variable that contains the data, for example: ${variable}
    • 

  • olderThan – the same as above, but says about older files
    • 

  • biggerThan – only files bigger than the value of the parameter will be taken into consideration
    • 

  • smallerThan –only files smaller than the value of this parameter will be taken into consideration
    • 



If you already have a list of files we can go further, the inner entity - its task is to download specific data contained in the files. The data is taken from the file specified by an external entity using a data source. The processor type: XpathEntityProcessor used for XML files have the following attributes:


    

  • url – the input data
    • 

  • useSolrAddSchema – information, that the input data is in Solr XML format
    • 

  • stream – should we use stream for document processing. In case of large XML files, it's good to use stream="true" which will  use far less memory and won't try to load the whole XML file into the memory.
    • 



Additional parameters are not useful in our case and we describe them on another occasion:)


But why all this?


The example allows to read all XML files from the selected directory. We used exactly the same file format as the "classical" method of sending documents to Solr using HTTP POST. So why use this method?


Push and Pull


The first argument can be the control of the connections between the Solr server and the system that is responsible for generating the files that are going to be indexed. When we do not have full control over the data source, it's better to retrieve the data from the source than to provide additional services that could potentially become a target of attack.


Prototyping and change testing


How does it work in practice? In my case I decided to add the possibility of a more advanced search and an ability to do faceting on the category tree. The document contained the "category" field, where it stored the path such as "Cars / Four sits / Audi". To create a new queries, we should have an additional fields in the index that hold the category name, the level of the category and also how many levels we have.


To add the required fields we used the ability to define scripts. Quoted previously imported file now looks like this:





Note at the end


When using DIH we need to be aware that it works a little differently. In particular, the attempt to load multiple values ​​to a field that is not multivalued (in the schema.xml file) in DIH succeeds - the excess value will be ignored. In the case of "classical" indexing method Solr will return an error.


{document.fileAbsolutePath}"

        useSolrAddSchema="true"

        stream="true">

      </entity>

    </entity>

  </document>

</dataConfig>


Explanation of the example


In comparison with the examples from the earlier articles a new type appeared – the FileDataSource. Example of a complete call:





The additional, not mandatory attributes are obvious:


    

  • basePath – the directory which will be used to calculate the relative path of the “entity” tag
    • 

  • encoding – the file encoding (default: the OS default encoding)
    • 



After the source definition, we have document definition with two nested entities.


The purpose of the main entity is to generate the files list. To do that, we use the FileListEntityProcessor.This entity is self-supporting and doesn’t need any data source (thus dataSource=”null”). The used attributes:


    

  • fileName (mandatory) – regular expression that says which files to choose
    • 

  • recursive – should subdirectories be checked  (default: no)
    • 

  • rootEntity – says about if the data from the entity should be treated as documents source. Because we don’t want to index files list, which this entity provides, we need to set this attribute to false. After setting this attribute to false the next entity will be treated as main entity and its data will be indexed.
    • 

  • baseDir (mandatory) – the directory where the files should be located
    • 

  • dataSource – in this case we set this parameter to “null” because the entity doesn’t use data source  (we can ommit this parameter in Solr > 1.3)
    • 

  • excludes – regular expression which says which files to exclude from indexing
    • 

  • newerThan – says, that only files newer that the parameter value will be taken into consideration. This parameter can take a value in the format: YYYY-MM-dd HH:mm:ss or a single quoted string, like: ‘NOW – 7DAYS’ or an variable that contains the data, for example: ${variable}
    • 

  • olderThan – the same as above, but says about older files
    • 

  • biggerThan – only files bigger than the value of the parameter will be taken into consideration
    • 

  • smallerThan –only files smaller than the value of this parameter will be taken into consideration
    • 



If you already have a list of files we can go further, the inner entity – its task is to download specific data contained in the files. The data is taken from the file specified by an external entity using a data source. The processor type: XpathEntityProcessor used for XML files have the following attributes:


    

  • url – the input data
    • 

  • useSolrAddSchema – information, that the input data is in Solr XML format
    • 

  • stream – should we use stream for document processing. In case of large XML files, it’s good to use stream=”true” which will  use far less memory and won’t try to load the whole XML file into the memory.
    • 



Additional parameters are not useful in our case and we describe them on another occasion:)


But why all this?


The example allows to read all XML files from the selected directory. We used exactly the same file format as the “classical” method of sending documents to Solr using HTTP POST. So why use this method?


Push and Pull


The first argument can be the control of the connections between the Solr server and the system that is responsible for generating the files that are going to be indexed. When we do not have full control over the data source, it’s better to retrieve the data from the source than to provide additional services that could potentially become a target of attack.


Prototyping and change testing


How does it work in practice? In my case I decided to add the possibility of a more advanced search and an ability to do faceting on the category tree. The document contained the “category” field, where it stored the path such as “Cars / Four sits / Audi”. To create a new queries, we should have an additional fields in the index that hold the category name, the level of the category and also how many levels we have.


To add the required fields we used the ability to define scripts. Quoted previously imported file now looks like this:





Note at the end


When using DIH we need to be aware that it works a little differently. In particular, the attempt to load multiple values ​​to a field that is not multivalued (in the schema.xml file) in DIH succeeds – the excess value will be ignored. In the case of “classical” indexing method Solr will return an error.


{document.fileAbsolutePath}”

        useSolrAddSchema=”true”

        stream=”true”>

      </entity>

    </entity>

  </document>

</dataConfig>


Note at the end


When using DIH we need to be aware that it works a little differently. In particular, the attempt to load multiple values ​​to a field that is not multivalued (in the schema.xml file) in DIH succeeds – the excess value will be ignored. In the case of “classical” indexing method Solr will return an error.


”

      recursive=”false”

      rootEntity=”false”

      dataSource=”null”>

      <entity

        processor=”XPathEntityProcessor”

        url=”


Explanation of the example


In comparison with the examples from the earlier articles a new type appeared – the FileDataSource. Example of a complete call:





The additional, not mandatory attributes are obvious:


    

  • basePath – the directory which will be used to calculate the relative path of the “entity” tag
    • 

  • encoding – the file encoding (default: the OS default encoding)
    • 



After the source definition, we have document definition with two nested entities.


The purpose of the main entity is to generate the files list. To do that, we use the FileListEntityProcessor.This entity is self-supporting and doesn’t need any data source (thus dataSource=”null”). The used attributes:


    

  • fileName (mandatory) – regular expression that says which files to choose
    • 

  • recursive – should subdirectories be checked  (default: no)
    • 

  • rootEntity – says about if the data from the entity should be treated as documents source. Because we don’t want to index files list, which this entity provides, we need to set this attribute to false. After setting this attribute to false the next entity will be treated as main entity and its data will be indexed.
    • 

  • baseDir (mandatory) – the directory where the files should be located
    • 

  • dataSource – in this case we set this parameter to “null” because the entity doesn’t use data source  (we can ommit this parameter in Solr > 1.3)
    • 

  • excludes – regular expression which says which files to exclude from indexing
    • 

  • newerThan – says, that only files newer that the parameter value will be taken into consideration. This parameter can take a value in the format: YYYY-MM-dd HH:mm:ss or a single quoted string, like: ‘NOW – 7DAYS’ or an variable that contains the data, for example: ${variable}
    • 

  • olderThan – the same as above, but says about older files
    • 

  • biggerThan – only files bigger than the value of the parameter will be taken into consideration
    • 

  • smallerThan –only files smaller than the value of this parameter will be taken into consideration
    • 



If you already have a list of files we can go further, the inner entity – its task is to download specific data contained in the files. The data is taken from the file specified by an external entity using a data source. The processor type: XpathEntityProcessor used for XML files have the following attributes:


    

  • url – the input data
    • 

  • useSolrAddSchema – information, that the input data is in Solr XML format
    • 

  • stream – should we use stream for document processing. In case of large XML files, it’s good to use stream=”true” which will  use far less memory and won’t try to load the whole XML file into the memory.
    • 



Additional parameters are not useful in our case and we describe them on another occasion:)


But why all this?


The example allows to read all XML files from the selected directory. We used exactly the same file format as the “classical” method of sending documents to Solr using HTTP POST. So why use this method?


Push and Pull


The first argument can be the control of the connections between the Solr server and the system that is responsible for generating the files that are going to be indexed. When we do not have full control over the data source, it’s better to retrieve the data from the source than to provide additional services that could potentially become a target of attack.


Prototyping and change testing


How does it work in practice? In my case I decided to add the possibility of a more advanced search and an ability to do faceting on the category tree. The document contained the “category” field, where it stored the path such as “Cars / Four sits / Audi”. To create a new queries, we should have an additional fields in the index that hold the category name, the level of the category and also how many levels we have.


To add the required fields we used the ability to define scripts. Quoted previously imported file now looks like this:





Note at the end


When using DIH we need to be aware that it works a little differently. In particular, the attempt to load multiple values ​​to a field that is not multivalued (in the schema.xml file) in DIH succeeds – the excess value will be ignored. In the case of “classical” indexing method Solr will return an error.


{document.fileAbsolutePath}”

        useSolrAddSchema=”true”

        stream=”true”>

      </entity>

    </entity>

  </document>

</dataConfig>


Explanation of the example


In comparison with the examples from the earlier articles a new type appeared – the FileDataSource. Example of a complete call:





The additional, not mandatory attributes are obvious:


    

  • basePath – the directory which will be used to calculate the relative path of the “entity” tag
    • 

  • encoding – the file encoding (default: the OS default encoding)
    • 



After the source definition, we have document definition with two nested entities.


The purpose of the main entity is to generate the files list. To do that, we use the FileListEntityProcessor.This entity is self-supporting and doesn’t need any data source (thus dataSource=”null”). The used attributes:


    

  • fileName (mandatory) – regular expression that says which files to choose
    • 

  • recursive – should subdirectories be checked  (default: no)
    • 

  • rootEntity – says about if the data from the entity should be treated as documents source. Because we don’t want to index files list, which this entity provides, we need to set this attribute to false. After setting this attribute to false the next entity will be treated as main entity and its data will be indexed.
    • 

  • baseDir (mandatory) – the directory where the files should be located
    • 

  • dataSource – in this case we set this parameter to “null” because the entity doesn’t use data source  (we can ommit this parameter in Solr > 1.3)
    • 

  • excludes – regular expression which says which files to exclude from indexing
    • 

  • newerThan – says, that only files newer that the parameter value will be taken into consideration. This parameter can take a value in the format: YYYY-MM-dd HH:mm:ss or a single quoted string, like: ‘NOW – 7DAYS’ or an variable that contains the data, for example: ${variable}
    • 

  • olderThan – the same as above, but says about older files
    • 

  • biggerThan – only files bigger than the value of the parameter will be taken into consideration
    • 

  • smallerThan –only files smaller than the value of this parameter will be taken into consideration
    • 



If you already have a list of files we can go further, the inner entity – its task is to download specific data contained in the files. The data is taken from the file specified by an external entity using a data source. The processor type: XpathEntityProcessor used for XML files have the following attributes:


    

  • url – the input data
    • 

  • useSolrAddSchema – information, that the input data is in Solr XML format
    • 

  • stream – should we use stream for document processing. In case of large XML files, it’s good to use stream=”true” which will  use far less memory and won’t try to load the whole XML file into the memory.
    • 



Additional parameters are not useful in our case and we describe them on another occasion:)


But why all this?


The example allows to read all XML files from the selected directory. We used exactly the same file format as the “classical” method of sending documents to Solr using HTTP POST. So why use this method?


Push and Pull


The first argument can be the control of the connections between the Solr server and the system that is responsible for generating the files that are going to be indexed. When we do not have full control over the data source, it’s better to retrieve the data from the source than to provide additional services that could potentially become a target of attack.


Prototyping and change testing


How does it work in practice? In my case I decided to add the possibility of a more advanced search and an ability to do faceting on the category tree. The document contained the “category” field, where it stored the path such as “Cars / Four sits / Audi”. To create a new queries, we should have an additional fields in the index that hold the category name, the level of the category and also how many levels we have.


To add the required fields we used the ability to define scripts. Quoted previously imported file now looks like this:





Note at the end


When using DIH we need to be aware that it works a little differently. In particular, the attempt to load multiple values ​​to a field that is not multivalued (in the schema.xml file) in DIH succeeds – the excess value will be ignored. In the case of “classical” indexing method Solr will return an error.

	


	

					
	
			
			
			



	
	
	
		

		
Leave a Reply 
Your email address will not be published. Required fields are marked *
 
 



 


 


 


	

	


		
	








		

	

			
		
	

	

    
    

                

                

                    

                        

							We use cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.							                        

                    

                    

                        

							                                

                                    Cookies settings
                                

								                                

                                    Accept
                                

								                        

                    

                

            

			            

                

                    

                    

                    

                        

                            Privacy & Cookie policy
                            
                        

                        

                            

								Privacy & Cookies policy                            

                            
Cookies list

                        

                        

                            

                                
                                

                                    Cookie name
                                    Active
                                

								        

            
				                    
				            
            
                
            
        

		                                
                            

                            

								


Privacy Policy






What information do we collect?

We collect information from you when you register on our site or place an order.

When ordering or registering on our site, as appropriate, you may be asked to enter your: name, e-mail address or mailing address.

What do we use your information for?

Any of the information we collect from you may be used in one of the following ways:

To personalize your experience
(your information helps us to better respond to your individual needs)
To improve our website
(we continually strive to improve our website offerings based on the information and feedback we receive from you)
To improve customer service
(your information helps us to more effectively respond to your customer service requests and support needs)

To process transactions
Your information, whether public or private, will not be sold, exchanged, transferred, or given to any other company for any reason whatsoever, without your consent, other than for the express purpose of delivering the purchased product or service requested.

To administer a contest, promotion, survey or other site feature

To send periodic emails
The email address you provide for order processing, will only be used to send you information and updates pertaining to your order.

How do we protect your information?

We implement a variety of security measures to maintain the safety of your personal information when you place an order or enter, submit, or access your personal information.

We offer the use of a secure server. All supplied sensitive/credit information is transmitted via Secure Socket Layer (SSL) technology and then encrypted into our Payment gateway providers database only to be accessible by those authorized with special access rights to such systems, and are required to?keep the information confidential.

After a transaction, your private information (credit cards, social security numbers, financials, etc.) will not be kept on file for more than 60 days.

Do we use cookies?

Yes (Cookies are small files that a site or its service provider transfers to your computers hard drive through your Web browser (if you allow) that enables the sites or service providers systems to recognize your browser and capture and remember certain information

We use cookies to help us remember and process the items in your shopping cart, understand and save your preferences for future visits, keep track of advertisements and compile aggregate data about site traffic and site interaction so that we can offer better site experiences and tools in the future. We may contract with third-party service providers to assist us in better understanding our site visitors. These service providers are not permitted to use the information collected on our behalf except to help us conduct and improve our business.

If you prefer, you can choose to have your computer warn you each time a cookie is being sent, or you can choose to turn off all cookies via your browser settings. Like most websites, if you turn your cookies off, some of our services may not function properly. However, you can still place orders by contacting customer service.

Google Analytics

We use Google Analytics on our sites for anonymous reporting of site usage and for advertising on the site. If you would like to opt-out of Google Analytics monitoring your behaviour on our sites please use this link (https://tools.google.com/dlpage/gaoptout/)

Do we disclose any information to outside parties?

We do not sell, trade, or otherwise transfer to outside parties your personally identifiable information. This does not include trusted third parties who assist us in operating our website, conducting our business, or servicing you, so long as those parties agree to keep this information confidential. We may also release your information when we believe release is appropriate to comply with the law, enforce our site policies, or protect ours or others rights, property, or safety. However, non-personally identifiable visitor information may be provided to other parties for marketing, advertising, or other uses.

Registration

The minimum information we need to register you is your name, email address and a password. We will ask you more questions for different services, including sales promotions. Unless we say otherwise, you have to answer all the registration questions.

We may also ask some other, voluntary questions during registration for certain services (for example, professional networks) so we can gain a clearer understanding of who you are. This also allows us to personalise services for you.

To assist us in our marketing, in addition to the data that you provide to us if you register, we may also obtain data from trusted third parties to help us understand what you might be interested in. This ‘profiling’ information is produced from a variety of sources, including publicly available data (such as the electoral roll) or from sources such as surveys and polls where you have given your permission for your data to be shared. You can choose not to have such data shared with the Guardian from these sources by logging into your account and changing the settings in the privacy section.

After you have registered, and with your permission, we may send you emails we think may interest you. Newsletters may be personalised based on what you have been reading on theguardian.com. At any time you can decide not to receive these emails and will be able to ‘unsubscribe’.

Logging in using social networking credentials

If you log-in to our sites using a Facebook log-in, you are granting permission to Facebook to share your user details with us. This will include your name, email address, date of birth and location which will then be used to form a Guardian identity. You can also use your picture from Facebook as part of your profile. This will also allow us and Facebook to share your, networks, user ID and any other information you choose to share according to your Facebook account settings. If you remove the Guardian app from your Facebook settings, we will no longer have access to this information.

If you log-in to our sites using a Google log-in, you grant permission to Google to share your user details with us. This will include your name, email address, date of birth, sex and location which we will then use to form a Guardian identity. You may use your picture from Google as part of your profile. This also allows us to share your networks, user ID and any other information you choose to share according to your Google account settings. If you remove the Guardian from your Google settings, we will no longer have access to this information.

If you log-in to our sites using a twitter log-in, we receive your avatar (the small picture that appears next to your tweets) and twitter username.

Children’s Online Privacy Protection Act Compliance

We are in compliance with the requirements of COPPA (Childrens Online Privacy Protection Act), we do not collect any information from anyone under 13 years of age. Our website, products and services are all directed to people who are at least 13 years old or older.

Updating your personal information

We offer a ‘My details’ page (also known as Dashboard), where you can update your personal information at any time, and change your marketing preferences. You can get to this page from most pages on the site – simply click on the ‘My details’ link at the top of the screen when you are signed in.

Online Privacy Policy Only

This online privacy policy applies only to information collected through our website and not to information collected offline.

Your Consent

By using our site, you consent to our privacy policy.

Changes to our Privacy Policy

If we decide to change our privacy policy, we will post those changes on this page.


                            

                        

                                                

                                                                                    

			                                                    Save settings
			                    			                                                

                                                    

                    

                

            

			                

                    

                        Cookies settings