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.
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. (Feel welcome to have a read through http://lucene.apache.org/solr/features.html http://lucene.apache.org/solr/features.html ) 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? Adam Heath-2 wrote: > > madppiper wrote: >> Ah, yes indeed. > > You're still mumbling. > >> Sorry, about my mumbling today. To be a tiny bit more specific. I am of >> course only referring to the indexed product search. I know that Solr is >> based on Lucene and that both use a similar way of indexing new listed >> products (that is by adding, updating,removing new entities from/to the >> index through XML files). > > No, it doesn't. Lucene is an api; it doesn't use xml files to populate > it's internal database. > > Lucene doesn't index products. It provides an inverted index to records > of text fields(which can be tokenized(or not), compressed(or not), or > stored(or not). It's up to the application to decide which fields to > add to a record, and what the fields and records actually mean. > >> From as much as I understand, Lucene is the main search engine used >> within >> OFBiz (I hope we are NOT relying on cached Mysql-native Fulltext Queries >> here). New Products are added to or removed from the IndexTree through a >> xml >> script (just as they would in Solr). Lucene then provides the rest of the >> OFBiz environment with a regular search mechanism, as well as ranked >> indexing, sorting and yadayadayada. > > Um, no, lucene is not the *main* engine, not at all. Have you seen > ProductKeyword? > >> Lucene however, does not allow advanced Facetting, nor is it a standalone >> application. Both of these advantages are something that Solr provides. >> Therefore it would be great if one could easily switch both search >> engines... > > You say "program A has feature Z, so program A is obviously better", but > you never define feature Z. > > I suggest you go have your morning coffee first, and maybe wait 'til > after lunch. You're not helping your argument at all. > > ps: for our own internal websites, I've utilized both lucene and > nutch(which is based on hadoop and lucene), and in both of those cases, > you write *java* code to populate the lucene record with fields. No xml > is ever used. > > -- View this message in context: http://www.nabble.com/Replacing-Lucene-with-Solr-tp19412826p19414595.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
