date:20170717

Re: svn commit: r1794770 - in /ofbiz/ofbiz-plugins/trunk/lucene: ./ groovyScripts/content/ src/main/java/org/apache/ofbiz/content/search/

2017-07-17 Thread Renuka Srishti

Hii,

I think during the solr/lucene version update, few changes are reverted
like *"combQuery = new BooleanQuery.Builder()" *in
lucene/groovyScripts/content/Search.groovy. The issue reported for the same
changes is OFBIZ-9301 .

Thanks

On Thu, May 11, 2017 at 5:28 AM,  wrote:

> Author: shijh
> Date: Wed May 10 23:58:31 2017
> New Revision: 1794770
>
> URL: http://svn.apache.org/viewvc?rev=1794770=rev
> Log:
> Fixed: Update Apache Solr/Lucene to release 6.2.1
> OFBIZ-8316
>
> Updated Lucene from 6.2.1 to 6.5.1 and the point fields generated by
> Lucene are ok now for Solr component.
>
> Thanks: Cao Pengan for the patch and Jacques, Michael for the comments and
> reviews.
>
> Modified:
> ofbiz/ofbiz-plugins/trunk/lucene/build.gradle
> ofbiz/ofbiz-plugins/trunk/lucene/groovyScripts/content/Search.groovy
> ofbiz/ofbiz-plugins/trunk/lucene/groovyScripts/content/
> SearchProducts.groovy
> ofbiz/ofbiz-plugins/trunk/lucene/src/main/java/org/
> apache/ofbiz/content/search/ProductDocument.java
> ofbiz/ofbiz-plugins/trunk/lucene/src/main/java/org/
> apache/ofbiz/content/search/SearchWorker.java
>
> Modified: ofbiz/ofbiz-plugins/trunk/lucene/build.gradle
> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
> lucene/build.gradle?rev=1794770=1794769=1794770=diff
> 
> ==
> --- ofbiz/ofbiz-plugins/trunk/lucene/build.gradle (original)
> +++ ofbiz/ofbiz-plugins/trunk/lucene/build.gradle Wed May 10 23:58:31 2017
> @@ -17,7 +17,7 @@
>   * under the License.
>   */
>  dependencies {
> -pluginLibsCompile 'org.apache.lucene:lucene-core:6.2.1'
> -pluginLibsCompile 'org.apache.lucene:lucene-queryparser:6.2.1'
> -pluginLibsCompile 'org.apache.lucene:lucene-analyzers-common:6.2.1'
> +pluginLibsCompile 'org.apache.lucene:lucene-core:6.5.1'
> +pluginLibsCompile 'org.apache.lucene:lucene-queryparser:6.5.1'
> +pluginLibsCompile 'org.apache.lucene:lucene-analyzers-common:6.5.1'
>  }
> \ No newline at end of file
>
> Modified: ofbiz/ofbiz-plugins/trunk/lucene/groovyScripts/content/
> Search.groovy
> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
> lucene/groovyScripts/content/Search.groovy?rev=1794770=
> 1794769=1794770=diff
> 
> ==
> --- ofbiz/ofbiz-plugins/trunk/lucene/groovyScripts/content/Search.groovy
> (original)
> +++ ofbiz/ofbiz-plugins/trunk/lucene/groovyScripts/content/Search.groovy
> Wed May 10 23:58:31 2017
> @@ -22,15 +22,13 @@ import org.apache.lucene.document.Docume
>  import org.apache.lucene.index.Term
>  import org.apache.lucene.queryparser.classic.QueryParser
>  import org.apache.lucene.store.FSDirectory
> -import org.apache.lucene.search.*
> -import org.apache.lucene.index.DirectoryReader
> -
>  import org.apache.ofbiz.base.util.UtilHttp
>  import org.apache.ofbiz.content.search.SearchWorker
>  import org.apache.ofbiz.product.feature.ParametricSearch
> +import org.apache.lucene.search.*
> +import org.apache.lucene.index.DirectoryReader
>  import org.apache.ofbiz.base.util.UtilProperties
>
> -
>  queryLine = parameters.queryLine
>
>  siteId = parameters.lcSiteId
> @@ -41,7 +39,7 @@ searchFeature3 = (String) parameters.SEA
>
>  featureIdByType = ParametricSearch.makeFeatureIdByTypeMap(
> UtilHttp.getParameterMap(request))
>
> -combQuery = new BooleanQuery.Builder()
> +combQuery = new BooleanQuery()
>
>  try {
>  DirectoryReader reader = DirectoryReader.open(FSDirectory.open(new
> File(SearchWorker.getIndexPath("content")).toPath()))
> @@ -66,7 +64,7 @@ if (queryLine || siteId) {
>  }
>
>  if (searchFeature1 || searchFeature2 || searchFeature3 ||
> !featureIdByType.isEmpty()) {
> -featureQuery = new BooleanQuery.Builder()
> +featureQuery = new BooleanQuery()
>  featuresRequired = BooleanClause.Occur.MUST
>  if ("any".equals(parameters.any_or_all)) {
>  featuresRequired = BooleanClause.Occur.SHOULD
> @@ -92,12 +90,12 @@ if (searchFeature1 || searchFeature2 ||
>  termQuery = new TermQuery(new Term("feature", value))
>  featureQuery.add(termQuery, featuresRequired)
>  }
> -combQuery.add(featureQuery.build(), featuresRequired)
> +combQuery.add(featureQuery, featuresRequired)
>  }
>  }
>  if (searcher) {
>  TopScoreDocCollector collector = TopScoreDocCollector.create(100)
> //defaulting to 100 results
> -searcher.search(combQuery.build(), collector)
> +searcher.search(combQuery, collector)
>  ScoreDoc[] hits = collector.topDocs().scoreDocs
>
>  contentList = [] as ArrayList
>
> Modified: ofbiz/ofbiz-plugins/trunk/lucene/groovyScripts/content/
> SearchProducts.groovy
> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
> lucene/groovyScripts/content/SearchProducts.groovy?rev=
> 1794770=1794769=1794770=diff
>

Re: [Proposal] moving all data in applications to the data-model component

2017-07-17 Thread Jacopo Cappellato

+1 to everything you wrote. I will do my best to help with the initiative.

Thank you Taher.

Jacopo

On Fri, Jul 14, 2017 at 11:59 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

>  Hello Everyone,
>
> Data loading in OFBiz is quite fragile. A small change could crash the
> system and finding out the reason can be difficult. I really felt the
> pain of this when trying to disentangle the framework from data
> dependencies on plugins [1].
>
> I've been thinking about a solution to reduce fragility, and here are
> my thoughts:
> - The less data files the better.
> - The less data the better.
> - The less distance (e.g. same directory) between data files the better.
> - No circular dependencies (file dependencies should be like a tree).
> - Fail fast [2].
>
> Therefore, I suggest the following action points:
> - Create a directory structure similar to [3] in the datamodel component.
> - For any data that two or more files depend on, immediately move it
> to the common-.xml file.
> - For any data that does not belong to any domain (e.g. marketing,
> content, etc ..) move it to the common-.xml.
> - Maintain a strict dependency hierarchy of demo -> seed -> seed-initial.
> - Gradually and carefully move data from all applications to the
> datamodel component as per above guidelines.
> - Cleanup and refactor the data as we move it including any tests that
> depend on it.
>
> What do you think of this proposal? Does it sound reasonable? Also
> given the size of what I'm proposing I think we need multiple people
> to work on this. So is anyone interested in taking part in this
> initiative?
>
> Cheers,
>
> Taher Alkhateeb
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-9322
> [2] https://lists.apache.org/thread.html/a18b5d4086a07ff34a0cb950999e8f
> 8e869a6aa7efa2fc866a75a7b6@%3Cdev.ofbiz.apache.org%3E
> [3] directory structure:
> data/
> ├── demo
> │   ├── accounting-demo.xml
> │   ├── common-demo.xml
> │   ├── content-demo.xml
> │   ├── humanres-demo.xml
> │   ├── manufacturing-demo.xml
> │   ├── marketing-demo.xml
> │   ├── order-demo.xml
> │   ├── party-demo.xml
> │   ├── product-demo.xml
> │   ├── shipment-demo.xml
> │   └── workeffort-demo.xml
> ├── seed
> │   ├── accounting-seed.xml
> │   ├── common-seed.xml
> │   ├── content-seed.xml
> │   ├── humanres-seed.xml
> │   ├── manufacturing-seed.xml
> │   ├── marketing-seed.xml
> │   ├── order-seed.xml
> │   ├── party-seed.xml
> │   ├── product-seed.xml
> │   ├── shipment-seed.xml
> │   └── workeffort-seed.xml
> └── seed-initial
> ├── accounting-seed-initial.xml
> ├── common-seed-initial.xml
> ├── content-seed-initial.xml
> ├── humanres-seed-initial.xml
> ├── manufacturing-seed-initial.xml
> ├── marketing-seed-initial.xml
> ├── order-seed-initial.xml
> ├── party-seed-initial.xml
> ├── product-seed-initial.xml
> ├── shipment-seed-initial.xml
> └── workeffort-seed-initial.xml
>

Re: [Proposal] moving all data in applications to the data-model component

2017-07-17 Thread Taher Alkhateeb

Hi Paul,

I don't have an opinion on plugins so far as I didn't think enough
about it. I just thought since we centralized the entities in
"data-model" we might as well centralize the data itself. Hopefully
we'll discuss architectural proposals for plugins at some point but
I'm trying to focus on cleaning stuff from the inside out.

With that being said, I always welcome ideas to enrich this
discussion, and I hope more people find this thread interesting to
pitch in.

On Mon, Jul 17, 2017 at 9:00 AM, Paul Foxworthy  wrote:
> Hi Taher,
>
> Makes sense to me.
>
> Would any plugin defining custom entities also have a similar /data tree?
>
> Cheers
>
> Paul
>
>
> On 14 July 2017 at 19:59, Taher Alkhateeb 
> wrote:
>
>>  Hello Everyone,
>>
>> Data loading in OFBiz is quite fragile. A small change could crash the
>> system and finding out the reason can be difficult. I really felt the
>> pain of this when trying to disentangle the framework from data
>> dependencies on plugins [1].
>>
>> I've been thinking about a solution to reduce fragility, and here are
>> my thoughts:
>> - The less data files the better.
>> - The less data the better.
>> - The less distance (e.g. same directory) between data files the better.
>> - No circular dependencies (file dependencies should be like a tree).
>> - Fail fast [2].
>>
>> Therefore, I suggest the following action points:
>> - Create a directory structure similar to [3] in the datamodel component.
>> - For any data that two or more files depend on, immediately move it
>> to the common-.xml file.
>> - For any data that does not belong to any domain (e.g. marketing,
>> content, etc ..) move it to the common-.xml.
>> - Maintain a strict dependency hierarchy of demo -> seed -> seed-initial.
>> - Gradually and carefully move data from all applications to the
>> datamodel component as per above guidelines.
>> - Cleanup and refactor the data as we move it including any tests that
>> depend on it.
>>
>> What do you think of this proposal? Does it sound reasonable? Also
>> given the size of what I'm proposing I think we need multiple people
>> to work on this. So is anyone interested in taking part in this
>> initiative?
>>
>> Cheers,
>>
>> Taher Alkhateeb
>>
>> [1] https://issues.apache.org/jira/browse/OFBIZ-9322
>> [2] https://lists.apache.org/thread.html/a18b5d4086a07ff34a0cb950999e8f
>> 8e869a6aa7efa2fc866a75a7b6@%3Cdev.ofbiz.apache.org%3E
>> [3] directory structure:
>> data/
>> ├── demo
>> │   ├── accounting-demo.xml
>> │   ├── common-demo.xml
>> │   ├── content-demo.xml
>> │   ├── humanres-demo.xml
>> │   ├── manufacturing-demo.xml
>> │   ├── marketing-demo.xml
>> │   ├── order-demo.xml
>> │   ├── party-demo.xml
>> │   ├── product-demo.xml
>> │   ├── shipment-demo.xml
>> │   └── workeffort-demo.xml
>> ├── seed
>> │   ├── accounting-seed.xml
>> │   ├── common-seed.xml
>> │   ├── content-seed.xml
>> │   ├── humanres-seed.xml
>> │   ├── manufacturing-seed.xml
>> │   ├── marketing-seed.xml
>> │   ├── order-seed.xml
>> │   ├── party-seed.xml
>> │   ├── product-seed.xml
>> │   ├── shipment-seed.xml
>> │   └── workeffort-seed.xml
>> └── seed-initial
>> ├── accounting-seed-initial.xml
>> ├── common-seed-initial.xml
>> ├── content-seed-initial.xml
>> ├── humanres-seed-initial.xml
>> ├── manufacturing-seed-initial.xml
>> ├── marketing-seed-initial.xml
>> ├── order-seed-initial.xml
>> ├── party-seed-initial.xml
>> ├── product-seed-initial.xml
>> ├── shipment-seed-initial.xml
>> └── workeffort-seed-initial.xml
>>
>
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: +61 3 9585 6788
> Web: http://www.coherentsoftware.com.au/
> Email: i...@coherentsoftware.com.au

Re: [Proposal] moving all data in applications to the data-model component

2017-07-17 Thread Paul Foxworthy

Hi Taher,

Makes sense to me.

Would any plugin defining custom entities also have a similar /data tree?

Cheers

Paul


On 14 July 2017 at 19:59, Taher Alkhateeb 
wrote:

>  Hello Everyone,
>
> Data loading in OFBiz is quite fragile. A small change could crash the
> system and finding out the reason can be difficult. I really felt the
> pain of this when trying to disentangle the framework from data
> dependencies on plugins [1].
>
> I've been thinking about a solution to reduce fragility, and here are
> my thoughts:
> - The less data files the better.
> - The less data the better.
> - The less distance (e.g. same directory) between data files the better.
> - No circular dependencies (file dependencies should be like a tree).
> - Fail fast [2].
>
> Therefore, I suggest the following action points:
> - Create a directory structure similar to [3] in the datamodel component.
> - For any data that two or more files depend on, immediately move it
> to the common-.xml file.
> - For any data that does not belong to any domain (e.g. marketing,
> content, etc ..) move it to the common-.xml.
> - Maintain a strict dependency hierarchy of demo -> seed -> seed-initial.
> - Gradually and carefully move data from all applications to the
> datamodel component as per above guidelines.
> - Cleanup and refactor the data as we move it including any tests that
> depend on it.
>
> What do you think of this proposal? Does it sound reasonable? Also
> given the size of what I'm proposing I think we need multiple people
> to work on this. So is anyone interested in taking part in this
> initiative?
>
> Cheers,
>
> Taher Alkhateeb
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-9322
> [2] https://lists.apache.org/thread.html/a18b5d4086a07ff34a0cb950999e8f
> 8e869a6aa7efa2fc866a75a7b6@%3Cdev.ofbiz.apache.org%3E
> [3] directory structure:
> data/
> ├── demo
> │   ├── accounting-demo.xml
> │   ├── common-demo.xml
> │   ├── content-demo.xml
> │   ├── humanres-demo.xml
> │   ├── manufacturing-demo.xml
> │   ├── marketing-demo.xml
> │   ├── order-demo.xml
> │   ├── party-demo.xml
> │   ├── product-demo.xml
> │   ├── shipment-demo.xml
> │   └── workeffort-demo.xml
> ├── seed
> │   ├── accounting-seed.xml
> │   ├── common-seed.xml
> │   ├── content-seed.xml
> │   ├── humanres-seed.xml
> │   ├── manufacturing-seed.xml
> │   ├── marketing-seed.xml
> │   ├── order-seed.xml
> │   ├── party-seed.xml
> │   ├── product-seed.xml
> │   ├── shipment-seed.xml
> │   └── workeffort-seed.xml
> └── seed-initial
> ├── accounting-seed-initial.xml
> ├── common-seed-initial.xml
> ├── content-seed-initial.xml
> ├── humanres-seed-initial.xml
> ├── manufacturing-seed-initial.xml
> ├── marketing-seed-initial.xml
> ├── order-seed-initial.xml
> ├── party-seed-initial.xml
> ├── product-seed-initial.xml
> ├── shipment-seed-initial.xml
> └── workeffort-seed-initial.xml
>



-- 
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: i...@coherentsoftware.com.au

Re: svn commit: r1794770 - in /ofbiz/ofbiz-plugins/trunk/lucene: ./ groovyScripts/content/ src/main/java/org/apache/ofbiz/content/search/

Re: [Proposal] moving all data in applications to the data-model component

Re: [Proposal] moving all data in applications to the data-model component

Re: [Proposal] moving all data in applications to the data-model component

4 matches

Site Navigation

Mail list logo

Footer information