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.....
