In solr 3.6 a new field became available : http://wiki.apache.org/solr/CurrencyField

Disadvantages of doing this is that we need another schema only for Solr 3.6...?

Ideas anyone?

Comments

pwolanin’s picture

Status: Active » Closed (won't fix)

This looks like an rather edge case for any Drupal use. I don't think we should worry about it for now.

j0rd’s picture

Status: Closed (won't fix) » Active

Not really an edge case, it's a new field, and the possibility to use it should be provided. I'm personally using Solr 4, because I need pseudo fields & field aliases.

I would recommend adding an alter hook to the end of apachesolr_index_key(). This would allow other module developers to extend the field types. Like say commerce_price indexing as currency.

Reason I need this new fields, is for sorts on prices. I have a global site, and events are added in local currency. I need to be able to sort by different prices in different currencies and solr can provide this for me.

I already have about 8 additional field mappings in my project which have been reasonably easy to implement, but this is the first field which requires me to add a new field type into my schema...but then I'm stuck with not being able to extend the module to understand the new currency field.

Other related issues:
#1409146: Add all possible index_types to apachesolr_index_key
#839030: Indexing the money module CCK field, then filter by price range

nick_vh’s picture

Could you take a stab at it and add it to the schema.xml? If we can get that far, we will also help you get the rest in place to support that new field.

j0rd’s picture

NOTE: These patches may not apply cleanly. I have hacked a little extra stuff into my solr. Also the fields are disabled by default in my schema.xml.patch as you'd need solr 3.6 or higher to use them.

Attached is my patch & schema. I've also included my snippet which converts commerce_price fields to the format apachesolr wants.

In my patch, I'm only altering the mappings between $index_key and schema field definitions. It's straight forward, gets called a single time on page load, and just removes the hudle of hardcoding.

I do think this module could be refactored slightly to do a much better job at mapping fields between solr and Drupal though. I think providing defaults as we are now, but allowing them to be overriden on a per node field basis on the field page, is a much better solution. I also think the mapping code could be improved for easy of development from a developers standpoint. With that said, this is currently the only issue I've had with the module I could solve by writting my own or altering indexing callbacks.


/**                               
 * Converts a price into it's decimal representation with out adding currency sign.
 *
 * This needs to be done because format solr expects needs to match: 
 * @link http://www.tutorialspoint.com/java/util/currency_getdefaultfractiondigits.htm
 *
 * @see commerce_currency_format()
*/
function MODULE_apachesolr_commerce_price_indexing_formatter($amount, $currency_code) {
  // First load the currency array.
  $currency = commerce_currency_load($currency_code);
  // Then convert the price amount to the currency's major unit decimal value.
  $amount = commerce_currency_amount_to_decimal($amount, $currency_code);

  // Format the price as a number. 
  $price = number_format(commerce_currency_round(abs($amount), $currency), $currency['decimals'], '.', '');
  return $price;
} 

j0rd’s picture

StatusFileSize
new426 bytes

It appears that the OpenExchangeRates.org provider does not in fact work. It looks like Solr code for this was created in May, and OpenExchangeRates started requiring an APP_ID in June.

I've created a script for now, which pulls data from OpenExchangeRates.org and creates the currency.xml file. I'll be using this to test.

Ideally Solr would resolve this issue on their end, otherwise I can see Drupal adding an end point, which proxies the request over with the app_id and you can configure Solr to hit the URL with out the app_id and I suspect it would work.

Either way, here's my PHP script.

j0rd’s picture

There's also this bug, as opencurrencies is returning currencies that Solr doesn't understand.

http://stackoverflow.com/questions/12761846/java-util-currency-getinstan...

I'll be in tomorrow to finish this up, but that's all for today.

UPDATE:

Also Solr complains currencies can not be multiple fields, so that line has to get removed from schema.xml. I previously didn't have it, but added it into schema.xml when I submitted the patch to be more complete.

j0rd’s picture

I do have currency field working in my current install.

Attached is a mega-patch which includes the various parts you'll need to get this working. Keep in mind, this patch also assumes you will be running apachesolr 4.x

Patches included:
http://drupal.org/node/1550964#comment-6609244
http://drupal.org/files/1550964-30-Solr_Service.patch

http://drupal.org/node/1550964#comment-6765506
http://drupal.org/files/solr4-removeWaitFlush-commit-1550964-38.patch

Along with these patches, I've included my modified schema.xml which includes currency fields, a patch very similar to apachesolr-indexkeys_alter-1543106-4.patch and a currency.xml file, which assists in performing the currency calculations.

j0rd’s picture

Problems with d.org didn't upload patch. Trying again.
Wrong patch. Grr. One more time.

j0rd’s picture

StatusFileSize
new80.74 KB

Here's the correct patch.

j0rd’s picture

Status: Active » Needs review

Changing to needs review for testbot.

Status: Needs review » Needs work

The last submitted patch, apachesolr-currencyfield-1543106-7.patch, failed testing.

drdam’s picture

Hello,

I'll try to fix this patch with the 7.x-1.x-dev frorm 2013-may-16