madppiper wrote: > Well, > > I am sorry to say this, but I don't think that insulting me would help a > healthy discussion at all - since I am new to the OFBiz environment and the > documents are really scattered all over the place, I don't think I have to > feel ashamed over not knowing OFBiz in each detail, nor should it hinder me > from asking this type of questions.
If I came off that harsh, then I apologize. But you haven't been making much of any sense yourself. First, you call lucene proprietary. Huh? Come again? Second, you say replacing lucene usage with solr would increase performance. That's not possible. It would slow things down. Let's just say that product searching was done with lucene, and it was switched to solr. Instead of the lucene searching being done in process, we'd now have to go to a separate process, serializing thru xml, then this other system would do an internal lucene query, then send results back thru xml. There's no way that could be faster. If you start talking about using solr's replication, then maybe you could get a speed increase. However, product searching is not where ofbiz spends most of it's time. Third, you mention facetting. What is that? It's not defined on the main website for solr. If it's such a whiz-bang fancy feature, then it should be prominently defined; it's not. Fourth, you ask what port lucene is running on? Huh? Lucene doesn't run on a port. It's not server software. It's an api for indexing documents. Fifth, you then say that solr and lucene index files in a similiar way. This is not entirely accurate. The way you stated it, it implies that solr and lucene are completely different tools, that just happen to have a similiar set of features. However, solr is built *on top of* lucene. Sixth, you go on to say that lucene is fed with xml files. It's not. It's an api, and it's up to the application to fetch the data, split it into fields, then hand it off to lucene for tokenizing/indexing. I'm getting bored now, but to summarize: You start talking about other programs, but the things you say are *not* what those other programs do. We can forgive your lack of knowledge about ofbiz. But when you are trying to sell use of another software project, and the statements you make show that you don't know what you are talking about, don't be upset if we don't respond favourably. ps: again, sorry if feel insulted by this, but it's obvious from reading your mails that you don't even know how the other software systems you are talking about are supposed to work. > To Continue the discussion however (...and hopefully put this all behind), I > still continue to believe that moving the OFBiz framework to a new > Searchengine could be a very valuable idea. In case of moving to Solr, the > indexed search (of products) would greatly benefit from such features as: > > # Support for Dynamic Faceted Browsing and Filtering > # Advanced, Configurable Text Analysis > # Multiple search indices > #etc. What are these? Definitions. Be a salesmen. Seal the deal. > (Feel welcome to have a read through > http://lucene.apache.org/solr/features.html > http://lucene.apache.org/solr/features.html ) As far as documentation goes, that page ranks right up there with the best of the ofbiz pages. Short, terse, and completely lacking in anything useful to digest. Filled with internal industry buzz-phrases that mean nothing to those who don't already have an intimate knowledge of the product. :| If you want us to look at this software, then don't make us do your work for you. While we are completely capable of cross-referencing undefined terms on that page, doing so would entail extra work on our part. We already have enough on our plates. And we have a system that is currently working. A new system would have to be much better, in order for us to consider switching to it, and dealing with the integration issues that occur. Plus, if we switch to some new tool, then we have to increase our working set to include the use of that tool, and continue to remember how it works going forward. > So from what you said, no matter how you said it, I have learnt that Lucene > is indeed the native search engine used by ofbiz and it is NOT fed through > XML files. (that makes sense, cause I couldn't find the respective XML files > mentioned - also explains what I found in > org.ofbiz.content.search.SearchServices). > So in order to use a different Searchengine, I would have to write my own > XML-File generator and feed the search engine with that, correct? Doesn't > the entityengine already do that with such data? Again, no, it does not use lucene. You're having a hard time understanding. The entityengine is not a free-form generic xml producer. It produces a raw dump, in xml form, of the database(in effect). While you might be able to massage that into something that solr can use(by way of xsl), it's not the way I would do this.
