refs #26 -- an initinal version

[aoeuidht]

我尝试写了一个初始版本。

1. item 每个属性，在配置文件中， 都是一个dict

{
  "tags": {           // 名称
    "index": {       // es index 相关配置
      "type": "string",
      "analyzer": "keyword"
    },
    "serialize": {       // 检索完成后，输出的配置
      "include": true,      // 是否包含在输出结果中
      "by": lambda site_id, item: blah blah        // 返回前通过 callback 处理
    },
    "massage": {         //  es 处理之前先对参数进行处理
      "by": "lambda site_item: blah blah",  // 写入前通过 callback 处理
      "erase": false    // 是否写入 es
    },
    "query": {  // 检索相关设置
      "keyword": {},  // 是否在关键词推荐中使用此字段
      "search": {   // 是否在搜索中使用此字段
        "weight": 1000     // 检索使用的权重
      }
    }
  }
}

按照这个配置，覆盖了绝大部分定制化的需求

1. 尚未覆盖的特殊处理
   • Search/views.py 108
   • Recommender/es_search_functions.py 120

这些处理方式比较特别，无法简单抽象成配置文件可以处理的方式； 另外系统中对字段的处理散落在各个文件，无法全部使用配置文件。

我建议对不需要特殊处理的字段使用配置文件进行管理，需要额外处理的，保持不便。 如果是新部署服务，没有历史包袱，可以直接使用这种方式来解决自定义字段的问题。

[jacobfan]

"index": { // es index 相关配置 "type": "string", "analyzer": "keyword" },

这种写法看起来像是某种简便的plugin写法，而不是high level描述性的配置文件。包括后面用callback。

我更倾向于将实现细节抽象出去，做成用户也可以写的配置。

[jacobfan]

尚未覆盖的特殊处理 Search/views.py 108

order_by_stock这种，我认为应该是让“class ProductsSearch”生成sort_field的地方变成一个method，可以被extend或override。可以参考某些framework的plugin的写法来设计。

Recommender/es_search_functions.py 120

这里可以提供两种可能性：

1. 在plugin中整体替换construct_query函数
2. construct_query提供一些可以供plugin接入的点，例如给should_query添加内容。

目标是不需要修改core代码，可以添加一些单独为客户开发的plugin代码就可以为客户定制系统的功能。

我认为可以参考一下其他framework怎么给plugin提供接口，以及aspect oriented programming的概念。

[jacobfan]

@sunliwen 请参加讨论。