`
jiuyuehe
  • 浏览: 181171 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

基于solr 4.0 的二次开发方案

阅读更多
     基于solr4.0 对分布式搜索服务的支持与优化。我也没做太多参考就选择了solr4.0
     关于solr的使用,入门,实战之类的网上资料很多。推荐是wiki 将的比较详细点。国内的太陈旧。
     对与solr 的二次开发方案,网上也一些资料。大部分思路如下:
    
  • 写一个代理proxy bean 用来设置搜索条件
  • 或是通过反射 将 solrInputDocument 与 bean 关联
  • 。。。。。。



看来看去跟我的需求都不是太符合。

作为一个二次开发者,我们是给系统开发者提供一个更加简单的接口,让他们非常轻松的使用solr 并且不需要关心solr 的一切配置。这是我对这次二次开发的理解。

上述的方案可行,但是有局限性,如果是二次开发者一个人使用还好,如果需要给其他开发者去使用的话,人家入手还是需要一点理解的。因为他要去修改schame.xml里面的东西,schame里面的配置又是相当抽象的。

那么是否可以这样:每一个开发者都编写一个相应xxx.xml放入相应的模块、项目下,然后schame.xml Xinclude 进来。他们可以公用分词器

其实这等于没说,还是一样需要去理解solr 的配置,唯一的好处是不需要不需要去动服务器的schame.xml 而且solr配置是否支持Xinclude 还是个问题。

不行那就换一种:
[color=red]schema.xml 里面提供了动态配置。按其约定*_xx,进行通配。
那我们只需要约定 一下索引字段的规则即可,例如:总共分为String,double,int date,然后怎么去选分词器。等等。。。
这里约定好了,那么就是bean 跟Document 之间的转化了。最好不要去转化,但是可以使用
 public class MyDoc extends SolrDocument 

这样类似的解决,因为solrInputDocument 开发出来的方法很少,而且一目了然,直接给他换个名字就ok[/color]

但是有Query 里面是必须要进行修改的。按照这种简单替换的方案不行,因为query 开发的方法非常多,而且逻辑复杂,不符合我们的要求,那怎么去修改呢??我也还没想好
欢迎大家拍砖讨论
0
14
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics