finding a variant with the required standard features can take long
Locked
finding a variant with the required standard features can take long
 
|
The new feature explosion is now most implemented and shows , in speed
as a big improvement. However.... Part of the problem to select the respective variant is now done after the features are selected. Because of the datamodel it takes a long time to find the applicable variant if there are many. this what i do now: for every 'variant' in the ProductAssoc entity i check if the related variant product has all the selected features as 'standard' in the ProductFeatureAppl entity. this however can take a long time.... How can we improve this? If we could add a field to the ProductAssoc entity called 'standardFeatures' and we copy in here all the standard productFeatureId's of a related variant separated with a '|' sign when the features are updated, then we could find the related variant with one read...... This copy can be done with an eca... what is the opinion of the community? regards, Hans Bakker -- AntWebsystems.com: Quality OFBiz services for competitive rates..... |
Re: finding a variant with the required standard features can take long
|
Why not just use a view-entity to reduce round-trips to the database and select by the productId and the relevant feature ids? -David On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: > The new feature explosion is now most implemented and shows , in speed > as a big improvement. However.... > Part of the problem to select the respective variant is now done after > the features are selected. Because of the datamodel it takes a long > time > to find the applicable variant if there are many. > > this what i do now: > for every 'variant' in the ProductAssoc entity i check if the related > variant product has all the selected features as 'standard' in the > ProductFeatureAppl entity. > > this however can take a long time.... > > How can we improve this? > > If we could add a field to the ProductAssoc entity called > 'standardFeatures' and we copy in here all the standard > productFeatureId's of a related variant separated with a '|' sign when > the features are updated, then we could find the related variant with > one read...... > This copy can be done with an eca... > > what is the opinion of the community? > > regards, > Hans Bakker > -- > AntWebsystems.com: Quality OFBiz services for competitive rates..... > |
Re: finding a variant with the required standard features can take long
|
|
the problem is that the actual variants are stored in productAssoc and
the standard features in different records of productFeatureAppl.... any idea how this view would look like? so i want a variant from product assoc which has all the selected features on the screen as standard features in productFeatureAppl.... On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: > Why not just use a view-entity to reduce round-trips to the database > and select by the productId and the relevant feature ids? > > -David > > > On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: > > The new feature explosion is now most implemented and shows , in speed > > as a big improvement. However.... > > Part of the problem to select the respective variant is now done after > > the features are selected. Because of the datamodel it takes a long > > time > > to find the applicable variant if there are many. > > > > this what i do now: > > for every 'variant' in the ProductAssoc entity i check if the related > > variant product has all the selected features as 'standard' in the > > ProductFeatureAppl entity. > > > > this however can take a long time.... > > > > How can we improve this? > > > > If we could add a field to the ProductAssoc entity called > > 'standardFeatures' and we copy in here all the standard > > productFeatureId's of a related variant separated with a '|' sign when > > the features are updated, then we could find the related variant with > > one read...... > > This copy can be done with an eca... > > > > what is the opinion of the community? > > > > regards, > > Hans Bakker > > -- > > AntWebsystems.com: Quality OFBiz services for competitive rates..... > > > > AntWebsystems.com: Quality OFBiz services for competitive rates..... |
Re: finding a variant with the required standard features can take long
|
|
You would need to join the ProductFeatureAppl entity into the view multiple times (once for each feature selected). -David On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: > the problem is that the actual variants are stored in productAssoc and > the standard features in different records of productFeatureAppl.... > > any idea how this view would look like? > > so i want a variant from product assoc which has all the selected > features on the screen as standard features in productFeatureAppl.... > > > On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: >> Why not just use a view-entity to reduce round-trips to the database >> and select by the productId and the relevant feature ids? >> >> -David >> >> >> On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: >>> The new feature explosion is now most implemented and shows , in >>> speed >>> as a big improvement. However.... >>> Part of the problem to select the respective variant is now done >>> after >>> the features are selected. Because of the datamodel it takes a long >>> time >>> to find the applicable variant if there are many. >>> >>> this what i do now: >>> for every 'variant' in the ProductAssoc entity i check if the >>> related >>> variant product has all the selected features as 'standard' in the >>> ProductFeatureAppl entity. >>> >>> this however can take a long time.... >>> >>> How can we improve this? >>> >>> If we could add a field to the ProductAssoc entity called >>> 'standardFeatures' and we copy in here all the standard >>> productFeatureId's of a related variant separated with a '|' sign >>> when >>> the features are updated, then we could find the related variant >>> with >>> one read...... >>> This copy can be done with an eca... >>> >>> what is the opinion of the community? >>> >>> regards, >>> Hans Bakker >>> -- >>> AntWebsystems.com: Quality OFBiz services for competitive rates..... >>> >> >> > -- > AntWebsystems.com: Quality OFBiz services for competitive rates..... > |
Re: finding a variant with the required standard features can take long
|
|
David, thanks for your help,
i would understand that if they were different fields...but these are the same fields with different values on different records..... regards, Hans On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote: > You would need to join the ProductFeatureAppl entity into the view > multiple times (once for each feature selected). > > -David > > > On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: > > the problem is that the actual variants are stored in productAssoc and > > the standard features in different records of productFeatureAppl.... > > > > any idea how this view would look like? > > > > so i want a variant from product assoc which has all the selected > > features on the screen as standard features in productFeatureAppl.... > > > > > > On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: > >> Why not just use a view-entity to reduce round-trips to the database > >> and select by the productId and the relevant feature ids? > >> > >> -David > >> > >> > >> On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: > >>> The new feature explosion is now most implemented and shows , in > >>> speed > >>> as a big improvement. However.... > >>> Part of the problem to select the respective variant is now done > >>> after > >>> the features are selected. Because of the datamodel it takes a long > >>> time > >>> to find the applicable variant if there are many. > >>> > >>> this what i do now: > >>> for every 'variant' in the ProductAssoc entity i check if the > >>> related > >>> variant product has all the selected features as 'standard' in the > >>> ProductFeatureAppl entity. > >>> > >>> this however can take a long time.... > >>> > >>> How can we improve this? > >>> > >>> If we could add a field to the ProductAssoc entity called > >>> 'standardFeatures' and we copy in here all the standard > >>> productFeatureId's of a related variant separated with a '|' sign > >>> when > >>> the features are updated, then we could find the related variant > >>> with > >>> one read...... > >>> This copy can be done with an eca... > >>> > >>> what is the opinion of the community? > >>> > >>> regards, > >>> Hans Bakker > >>> -- > >>> AntWebsystems.com: Quality OFBiz services for competitive rates..... > >>> > >> > >> > > -- > > AntWebsystems.com: Quality OFBiz services for competitive rates..... > > > > AntWebsystems.com: Quality OFBiz services for competitive rates..... |
Re: finding a variant with the required standard features can take long
|
|
Yes, exactly, and that is what including the same entity multiple times as different member-entities with different aliases in a view- entity is all about. For some nice complex examples of this (hopefully more complex than you'll need) check out the ProductSearch.java stuff. The code there is split around, but search for "ProductKeyword" and you'll see that entity linked in multiple times so that multiple keyword records for a single product can be considered. -David On Apr 24, 2008, at 11:54 PM, Hans Bakker wrote: > David, thanks for your help, > > i would understand that if they were different fields...but these are > the same fields with different values on different records..... > > regards, > Hans > > On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote: >> You would need to join the ProductFeatureAppl entity into the view >> multiple times (once for each feature selected). >> >> -David >> >> >> On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: >>> the problem is that the actual variants are stored in productAssoc >>> and >>> the standard features in different records of productFeatureAppl.... >>> >>> any idea how this view would look like? >>> >>> so i want a variant from product assoc which has all the selected >>> features on the screen as standard features in >>> productFeatureAppl.... >>> >>> >>> On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: >>>> Why not just use a view-entity to reduce round-trips to the >>>> database >>>> and select by the productId and the relevant feature ids? >>>> >>>> -David >>>> >>>> >>>> On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: >>>>> The new feature explosion is now most implemented and shows , in >>>>> speed >>>>> as a big improvement. However.... >>>>> Part of the problem to select the respective variant is now done >>>>> after >>>>> the features are selected. Because of the datamodel it takes a >>>>> long >>>>> time >>>>> to find the applicable variant if there are many. >>>>> >>>>> this what i do now: >>>>> for every 'variant' in the ProductAssoc entity i check if the >>>>> related >>>>> variant product has all the selected features as 'standard' in the >>>>> ProductFeatureAppl entity. >>>>> >>>>> this however can take a long time.... >>>>> >>>>> How can we improve this? >>>>> >>>>> If we could add a field to the ProductAssoc entity called >>>>> 'standardFeatures' and we copy in here all the standard >>>>> productFeatureId's of a related variant separated with a '|' sign >>>>> when >>>>> the features are updated, then we could find the related variant >>>>> with >>>>> one read...... >>>>> This copy can be done with an eca... >>>>> >>>>> what is the opinion of the community? >>>>> >>>>> regards, >>>>> Hans Bakker >>>>> -- >>>>> AntWebsystems.com: Quality OFBiz services for competitive >>>>> rates..... >>>>> >>>> >>>> >>> -- >>> AntWebsystems.com: Quality OFBiz services for competitive rates..... >>> >> >> > -- > AntWebsystems.com: Quality OFBiz services for competitive rates..... > |
Re: finding a variant with the required standard features can take long
|
|
In reply to this post by hans_bakker
Hans Bakker wrote:
> The new feature explosion is now most implemented and shows , in speed > as a big improvement. However.... > Part of the problem to select the respective variant is now done after > the features are selected. Because of the datamodel it takes a long time > to find the applicable variant if there are many. > > this what i do now: > for every 'variant' in the ProductAssoc entity i check if the related > variant product has all the selected features as 'standard' in the > ProductFeatureAppl entity. > > this however can take a long time.... > > How can we improve this? > > If we could add a field to the ProductAssoc entity called > 'standardFeatures' and we copy in here all the standard > productFeatureId's of a related variant separated with a '|' sign when > the features are updated, then we could find the related variant with > one read...... > This copy can be done with an eca... > > what is the opinion of the community? > situation I want to actually show all the remaining valid features when one particular feature is selected as well as showing the final SKU when all features are selected. I do the first by constructing a pretty ridiculous graph that I keep in memory on the server to track feature exclusion. Its a hack but I can afford to throw memory at the problem and there are few enough products that it works. Not a general solution though, the graph needs to be turned into some kind of distilled feature product relationship table. I do the second by sorting the feature keys, concatenating them and then using that into a lookup of the actual variant. Probably kind of gross but it does the job. -- Ean Schuessler, CTO [hidden email] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com |
Re: finding a variant with the required standard features can take long
|
|
In reply to this post by David E Jones
Hi David,
i would appreciate a bit more info. I looked at the productSearch.java but could not really see an example of having the same field more then one time in a view and be able to select on it........ I use complexAlias for this? and how would the comparison look like? Thanks in advance, Regards, Hans On Fri, 2008-04-25 at 00:40 -0600, David E Jones wrote: > Yes, exactly, and that is what including the same entity multiple > times as different member-entities with different aliases in a view- > entity is all about. > > For some nice complex examples of this (hopefully more complex than > you'll need) check out the ProductSearch.java stuff. The code there is > split around, but search for "ProductKeyword" and you'll see that > entity linked in multiple times so that multiple keyword records for a > single product can be considered. > > -David > > > On Apr 24, 2008, at 11:54 PM, Hans Bakker wrote: > > David, thanks for your help, > > > > i would understand that if they were different fields...but these are > > the same fields with different values on different records..... > > > > regards, > > Hans > > > > On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote: > >> You would need to join the ProductFeatureAppl entity into the view > >> multiple times (once for each feature selected). > >> > >> -David > >> > >> > >> On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: > >>> the problem is that the actual variants are stored in productAssoc > >>> and > >>> the standard features in different records of productFeatureAppl.... > >>> > >>> any idea how this view would look like? > >>> > >>> so i want a variant from product assoc which has all the selected > >>> features on the screen as standard features in > >>> productFeatureAppl.... > >>> > >>> > >>> On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: > >>>> Why not just use a view-entity to reduce round-trips to the > >>>> database > >>>> and select by the productId and the relevant feature ids? > >>>> > >>>> -David > >>>> > >>>> > >>>> On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: > >>>>> The new feature explosion is now most implemented and shows , in > >>>>> speed > >>>>> as a big improvement. However.... > >>>>> Part of the problem to select the respective variant is now done > >>>>> after > >>>>> the features are selected. Because of the datamodel it takes a > >>>>> long > >>>>> time > >>>>> to find the applicable variant if there are many. > >>>>> > >>>>> this what i do now: > >>>>> for every 'variant' in the ProductAssoc entity i check if the > >>>>> related > >>>>> variant product has all the selected features as 'standard' in the > >>>>> ProductFeatureAppl entity. > >>>>> > >>>>> this however can take a long time.... > >>>>> > >>>>> How can we improve this? > >>>>> > >>>>> If we could add a field to the ProductAssoc entity called > >>>>> 'standardFeatures' and we copy in here all the standard > >>>>> productFeatureId's of a related variant separated with a '|' sign > >>>>> when > >>>>> the features are updated, then we could find the related variant > >>>>> with > >>>>> one read...... > >>>>> This copy can be done with an eca... > >>>>> > >>>>> what is the opinion of the community? > >>>>> > >>>>> regards, > >>>>> Hans Bakker > >>>>> -- > >>>>> AntWebsystems.com: Quality OFBiz services for competitive > >>>>> rates..... > >>>>> > >>>> > >>>> > >>> -- > >>> AntWebsystems.com: Quality OFBiz services for competitive rates..... > >>> > >> > >> > > -- > > AntWebsystems.com: Quality OFBiz services for competitive rates..... > > > > AntWebsystems.com: Quality OFBiz services for competitive rates..... |
Re: finding a variant with the required standard features can take long
|
|
Sorry, not sure what you're trying to do. What do you mean by "having the same field more then one time in a view and be able to select on it"? It sounds like you could do that with a couple of alias elements with different field aliases pointing to the same field name, and then in your delegator find call just have separate conditions for the different aliases... Is this from that other thread from a long time ago (don't remember when)? If so, add more detail as I can't remember what you were trying to do there, or if I ever even totally understood what it was. -David On May 19, 2008, at 1:17 AM, Hans Bakker wrote: > Hi David, > i would appreciate a bit more info. I looked at the productSearch.java > but could not really see an example of having the same field more then > one time in a view and be able to select on it........ > > I use complexAlias for this? and how would the comparison look like? > Thanks in advance, > > Regards, > Hans > > On Fri, 2008-04-25 at 00:40 -0600, David E Jones wrote: >> Yes, exactly, and that is what including the same entity multiple >> times as different member-entities with different aliases in a view- >> entity is all about. >> >> For some nice complex examples of this (hopefully more complex than >> you'll need) check out the ProductSearch.java stuff. The code there >> is >> split around, but search for "ProductKeyword" and you'll see that >> entity linked in multiple times so that multiple keyword records >> for a >> single product can be considered. >> >> -David >> >> >> On Apr 24, 2008, at 11:54 PM, Hans Bakker wrote: >>> David, thanks for your help, >>> >>> i would understand that if they were different fields...but these >>> are >>> the same fields with different values on different records..... >>> >>> regards, >>> Hans >>> >>> On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote: >>>> You would need to join the ProductFeatureAppl entity into the view >>>> multiple times (once for each feature selected). >>>> >>>> -David >>>> >>>> >>>> On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: >>>>> the problem is that the actual variants are stored in productAssoc >>>>> and >>>>> the standard features in different records of >>>>> productFeatureAppl.... >>>>> >>>>> any idea how this view would look like? >>>>> >>>>> so i want a variant from product assoc which has all the selected >>>>> features on the screen as standard features in >>>>> productFeatureAppl.... >>>>> >>>>> >>>>> On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: >>>>>> Why not just use a view-entity to reduce round-trips to the >>>>>> database >>>>>> and select by the productId and the relevant feature ids? >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: >>>>>>> The new feature explosion is now most implemented and shows , in >>>>>>> speed >>>>>>> as a big improvement. However.... >>>>>>> Part of the problem to select the respective variant is now done >>>>>>> after >>>>>>> the features are selected. Because of the datamodel it takes a >>>>>>> long >>>>>>> time >>>>>>> to find the applicable variant if there are many. >>>>>>> >>>>>>> this what i do now: >>>>>>> for every 'variant' in the ProductAssoc entity i check if the >>>>>>> related >>>>>>> variant product has all the selected features as 'standard' in >>>>>>> the >>>>>>> ProductFeatureAppl entity. >>>>>>> >>>>>>> this however can take a long time.... >>>>>>> >>>>>>> How can we improve this? >>>>>>> >>>>>>> If we could add a field to the ProductAssoc entity called >>>>>>> 'standardFeatures' and we copy in here all the standard >>>>>>> productFeatureId's of a related variant separated with a '|' >>>>>>> sign >>>>>>> when >>>>>>> the features are updated, then we could find the related variant >>>>>>> with >>>>>>> one read...... >>>>>>> This copy can be done with an eca... >>>>>>> >>>>>>> what is the opinion of the community? >>>>>>> >>>>>>> regards, >>>>>>> Hans Bakker >>>>>>> -- >>>>>>> AntWebsystems.com: Quality OFBiz services for competitive >>>>>>> rates..... >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>> AntWebsystems.com: Quality OFBiz services for competitive >>>>> rates..... >>>>> >>>> >>>> >>> -- >>> AntWebsystems.com: Quality OFBiz services for competitive rates..... >>> >> >> > -- > AntWebsystems.com: Quality OFBiz services for competitive rates..... > |
Re: finding a variant with the required standard features can take long
|
|
Hi David,
I want to find a product which a certain set of 4 standard features. In the ProductFeatureAppl entity i have the possibility to list all products with one certain standard feature. How to find a product with 4 specific standard features? Regards, Hans On Mon, 2008-05-19 at 01:28 -0600, David E Jones wrote: > Sorry, not sure what you're trying to do. What do you mean by "having > the same field more then one time in a view and be able to select on > it"? It sounds like you could do that with a couple of alias elements > with different field aliases pointing to the same field name, and then > in your delegator find call just have separate conditions for the > different aliases... > > Is this from that other thread from a long time ago (don't remember > when)? If so, add more detail as I can't remember what you were trying > to do there, or if I ever even totally understood what it was. > > -David > > > On May 19, 2008, at 1:17 AM, Hans Bakker wrote: > > > Hi David, > > i would appreciate a bit more info. I looked at the productSearch.java > > but could not really see an example of having the same field more then > > one time in a view and be able to select on it........ > > > > I use complexAlias for this? and how would the comparison look like? > > Thanks in advance, > > > > Regards, > > Hans > > > > On Fri, 2008-04-25 at 00:40 -0600, David E Jones wrote: > >> Yes, exactly, and that is what including the same entity multiple > >> times as different member-entities with different aliases in a view- > >> entity is all about. > >> > >> For some nice complex examples of this (hopefully more complex than > >> you'll need) check out the ProductSearch.java stuff. The code there > >> is > >> split around, but search for "ProductKeyword" and you'll see that > >> entity linked in multiple times so that multiple keyword records > >> for a > >> single product can be considered. > >> > >> -David > >> > >> > >> On Apr 24, 2008, at 11:54 PM, Hans Bakker wrote: > >>> David, thanks for your help, > >>> > >>> i would understand that if they were different fields...but these > >>> are > >>> the same fields with different values on different records..... > >>> > >>> regards, > >>> Hans > >>> > >>> On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote: > >>>> You would need to join the ProductFeatureAppl entity into the view > >>>> multiple times (once for each feature selected). > >>>> > >>>> -David > >>>> > >>>> > >>>> On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: > >>>>> the problem is that the actual variants are stored in productAssoc > >>>>> and > >>>>> the standard features in different records of > >>>>> productFeatureAppl.... > >>>>> > >>>>> any idea how this view would look like? > >>>>> > >>>>> so i want a variant from product assoc which has all the selected > >>>>> features on the screen as standard features in > >>>>> productFeatureAppl.... > >>>>> > >>>>> > >>>>> On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: > >>>>>> Why not just use a view-entity to reduce round-trips to the > >>>>>> database > >>>>>> and select by the productId and the relevant feature ids? > >>>>>> > >>>>>> -David > >>>>>> > >>>>>> > >>>>>> On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: > >>>>>>> The new feature explosion is now most implemented and shows , in > >>>>>>> speed > >>>>>>> as a big improvement. However.... > >>>>>>> Part of the problem to select the respective variant is now done > >>>>>>> after > >>>>>>> the features are selected. Because of the datamodel it takes a > >>>>>>> long > >>>>>>> time > >>>>>>> to find the applicable variant if there are many. > >>>>>>> > >>>>>>> this what i do now: > >>>>>>> for every 'variant' in the ProductAssoc entity i check if the > >>>>>>> related > >>>>>>> variant product has all the selected features as 'standard' in > >>>>>>> the > >>>>>>> ProductFeatureAppl entity. > >>>>>>> > >>>>>>> this however can take a long time.... > >>>>>>> > >>>>>>> How can we improve this? > >>>>>>> > >>>>>>> If we could add a field to the ProductAssoc entity called > >>>>>>> 'standardFeatures' and we copy in here all the standard > >>>>>>> productFeatureId's of a related variant separated with a '|' > >>>>>>> sign > >>>>>>> when > >>>>>>> the features are updated, then we could find the related variant > >>>>>>> with > >>>>>>> one read...... > >>>>>>> This copy can be done with an eca... > >>>>>>> > >>>>>>> what is the opinion of the community? > >>>>>>> > >>>>>>> regards, > >>>>>>> Hans Bakker > >>>>>>> -- > >>>>>>> AntWebsystems.com: Quality OFBiz services for competitive > >>>>>>> rates..... > >>>>>>> > >>>>>> > >>>>>> > >>>>> -- > >>>>> AntWebsystems.com: Quality OFBiz services for competitive > >>>>> rates..... > >>>>> > >>>> > >>>> > >>> -- > >>> AntWebsystems.com: Quality OFBiz services for competitive rates..... > >>> > >> > >> > > -- > > AntWebsystems.com: Quality OFBiz services for competitive rates..... > > > > AntWebsystems.com: Quality OFBiz services for competitive rates..... |
Re: finding a variant with the required standard features can take long
|
|
Hi Hans,
you have to join the ProductFeatureAppl 4 times (with 4 different aliases, of course), then you can set different constraints for the same fields of the for different aliases... Jacopo On May 19, 2008, at 9:38 AM, Hans Bakker wrote: > Hi David, > > I want to find a product which a certain set of 4 standard features. > > In the ProductFeatureAppl entity i have the possibility to list all > products with one certain standard feature. > > How to find a product with 4 specific standard features? > > Regards, > Hans > > > On Mon, 2008-05-19 at 01:28 -0600, David E Jones wrote: >> Sorry, not sure what you're trying to do. What do you mean by "having >> the same field more then one time in a view and be able to select on >> it"? It sounds like you could do that with a couple of alias elements >> with different field aliases pointing to the same field name, and >> then >> in your delegator find call just have separate conditions for the >> different aliases... >> >> Is this from that other thread from a long time ago (don't remember >> when)? If so, add more detail as I can't remember what you were >> trying >> to do there, or if I ever even totally understood what it was. >> >> -David >> >> >> On May 19, 2008, at 1:17 AM, Hans Bakker wrote: >> >>> Hi David, >>> i would appreciate a bit more info. I looked at the >>> productSearch.java >>> but could not really see an example of having the same field more >>> then >>> one time in a view and be able to select on it........ >>> >>> I use complexAlias for this? and how would the comparison look like? >>> Thanks in advance, >>> >>> Regards, >>> Hans >>> >>> On Fri, 2008-04-25 at 00:40 -0600, David E Jones wrote: >>>> Yes, exactly, and that is what including the same entity multiple >>>> times as different member-entities with different aliases in a >>>> view- >>>> entity is all about. >>>> >>>> For some nice complex examples of this (hopefully more complex than >>>> you'll need) check out the ProductSearch.java stuff. The code there >>>> is >>>> split around, but search for "ProductKeyword" and you'll see that >>>> entity linked in multiple times so that multiple keyword records >>>> for a >>>> single product can be considered. >>>> >>>> -David >>>> >>>> >>>> On Apr 24, 2008, at 11:54 PM, Hans Bakker wrote: >>>>> David, thanks for your help, >>>>> >>>>> i would understand that if they were different fields...but these >>>>> are >>>>> the same fields with different values on different records..... >>>>> >>>>> regards, >>>>> Hans >>>>> >>>>> On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote: >>>>>> You would need to join the ProductFeatureAppl entity into the >>>>>> view >>>>>> multiple times (once for each feature selected). >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: >>>>>>> the problem is that the actual variants are stored in >>>>>>> productAssoc >>>>>>> and >>>>>>> the standard features in different records of >>>>>>> productFeatureAppl.... >>>>>>> >>>>>>> any idea how this view would look like? >>>>>>> >>>>>>> so i want a variant from product assoc which has all the >>>>>>> selected >>>>>>> features on the screen as standard features in >>>>>>> productFeatureAppl.... >>>>>>> >>>>>>> >>>>>>> On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: >>>>>>>> Why not just use a view-entity to reduce round-trips to the >>>>>>>> database >>>>>>>> and select by the productId and the relevant feature ids? >>>>>>>> >>>>>>>> -David >>>>>>>> >>>>>>>> >>>>>>>> On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: >>>>>>>>> The new feature explosion is now most implemented and >>>>>>>>> shows , in >>>>>>>>> speed >>>>>>>>> as a big improvement. However.... >>>>>>>>> Part of the problem to select the respective variant is now >>>>>>>>> done >>>>>>>>> after >>>>>>>>> the features are selected. Because of the datamodel it takes a >>>>>>>>> long >>>>>>>>> time >>>>>>>>> to find the applicable variant if there are many. >>>>>>>>> >>>>>>>>> this what i do now: >>>>>>>>> for every 'variant' in the ProductAssoc entity i check if the >>>>>>>>> related >>>>>>>>> variant product has all the selected features as 'standard' in >>>>>>>>> the >>>>>>>>> ProductFeatureAppl entity. >>>>>>>>> >>>>>>>>> this however can take a long time.... >>>>>>>>> >>>>>>>>> How can we improve this? >>>>>>>>> >>>>>>>>> If we could add a field to the ProductAssoc entity called >>>>>>>>> 'standardFeatures' and we copy in here all the standard >>>>>>>>> productFeatureId's of a related variant separated with a '|' >>>>>>>>> sign >>>>>>>>> when >>>>>>>>> the features are updated, then we could find the related >>>>>>>>> variant >>>>>>>>> with >>>>>>>>> one read...... >>>>>>>>> This copy can be done with an eca... >>>>>>>>> >>>>>>>>> what is the opinion of the community? >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Hans Bakker >>>>>>>>> -- >>>>>>>>> AntWebsystems.com: Quality OFBiz services for competitive >>>>>>>>> rates..... >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> AntWebsystems.com: Quality OFBiz services for competitive >>>>>>> rates..... >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>> AntWebsystems.com: Quality OFBiz services for competitive >>>>> rates..... >>>>> >>>> >>>> >>> -- >>> AntWebsystems.com: Quality OFBiz services for competitive rates..... >>> >> >> > -- > AntWebsystems.com: Quality OFBiz services for competitive rates..... > |
Re: finding a variant with the required standard features can take long
|
|
In reply to this post by hans_bakker
Hi Hans
I think there code David was referring to starts at line 286 in ProductSearch.java, you'll see that a join on ProductKeyword gets added for each keyword. Regards Scott 2008/5/19 Hans Bakker <[hidden email]>: > Hi David, > i would appreciate a bit more info. I looked at the productSearch.java > but could not really see an example of having the same field more then > one time in a view and be able to select on it........ > > I use complexAlias for this? and how would the comparison look like? > Thanks in advance, > > Regards, > Hans > > On Fri, 2008-04-25 at 00:40 -0600, David E Jones wrote: > > Yes, exactly, and that is what including the same entity multiple > > times as different member-entities with different aliases in a view- > > entity is all about. > > > > For some nice complex examples of this (hopefully more complex than > > you'll need) check out the ProductSearch.java stuff. The code there is > > split around, but search for "ProductKeyword" and you'll see that > > entity linked in multiple times so that multiple keyword records for a > > single product can be considered. > > > > -David > > > > > > On Apr 24, 2008, at 11:54 PM, Hans Bakker wrote: > > > David, thanks for your help, > > > > > > i would understand that if they were different fields...but these are > > > the same fields with different values on different records..... > > > > > > regards, > > > Hans > > > > > > On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote: > > >> You would need to join the ProductFeatureAppl entity into the view > > >> multiple times (once for each feature selected). > > >> > > >> -David > > >> > > >> > > >> On Apr 24, 2008, at 10:29 PM, Hans Bakker wrote: > > >>> the problem is that the actual variants are stored in productAssoc > > >>> and > > >>> the standard features in different records of productFeatureAppl.... > > >>> > > >>> any idea how this view would look like? > > >>> > > >>> so i want a variant from product assoc which has all the selected > > >>> features on the screen as standard features in > > >>> productFeatureAppl.... > > >>> > > >>> > > >>> On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote: > > >>>> Why not just use a view-entity to reduce round-trips to the > > >>>> database > > >>>> and select by the productId and the relevant feature ids? > > >>>> > > >>>> -David > > >>>> > > >>>> > > >>>> On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote: > > >>>>> The new feature explosion is now most implemented and shows , in > > >>>>> speed > > >>>>> as a big improvement. However.... > > >>>>> Part of the problem to select the respective variant is now done > > >>>>> after > > >>>>> the features are selected. Because of the datamodel it takes a > > >>>>> long > > >>>>> time > > >>>>> to find the applicable variant if there are many. > > >>>>> > > >>>>> this what i do now: > > >>>>> for every 'variant' in the ProductAssoc entity i check if the > > >>>>> related > > >>>>> variant product has all the selected features as 'standard' in the > > >>>>> ProductFeatureAppl entity. > > >>>>> > > >>>>> this however can take a long time.... > > >>>>> > > >>>>> How can we improve this? > > >>>>> > > >>>>> If we could add a field to the ProductAssoc entity called > > >>>>> 'standardFeatures' and we copy in here all the standard > > >>>>> productFeatureId's of a related variant separated with a '|' sign > > >>>>> when > > >>>>> the features are updated, then we could find the related variant > > >>>>> with > > >>>>> one read...... > > >>>>> This copy can be done with an eca... > > >>>>> > > >>>>> what is the opinion of the community? > > >>>>> > > >>>>> regards, > > >>>>> Hans Bakker > > >>>>> -- > > >>>>> AntWebsystems.com: Quality OFBiz services for competitive > > >>>>> rates..... > > >>>>> > > >>>> > > >>>> > > >>> -- > > >>> AntWebsystems.com: Quality OFBiz services for competitive rates..... > > >>> > > >> > > >> > > > -- > > > AntWebsystems.com: Quality OFBiz services for competitive rates..... > > > > > > > > -- > AntWebsystems.com: Quality OFBiz services for competitive rates..... > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |