You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adam Heath <do...@brainfood.com> on 2010/07/02 16:25:01 UTC
Re: svn commit: r959943 - /ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonWorkers.java
jleroux@apache.org wrote:
> Author: jleroux
> Date: Fri Jul 2 10:32:58 2010
> New Revision: 959943
>
> URL: http://svn.apache.org/viewvc?rev=959943&view=rev
> Log:
> Revert r959673 on Scott's advice. There is already a getCategoryMembers. A bit different but it's ok, as it does not make much sense to sort categoryMembers with another field than sequenceNum
Sorting by name?
Re: svn commit: r959943 - /ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonWorkers.java
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adam Heath" <do...@brainfood.com>
> Jacques Le Roux wrote:
>> From: "Adam Heath" <do...@brainfood.com>
>>> jleroux@apache.org wrote:
>>>> Author: jleroux
>>>> Date: Fri Jul 2 10:32:58 2010
>>>> New Revision: 959943
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=959943&view=rev
>>>> Log:
>>>> Revert r959673 on Scott's advice. There is already a
>>>> getCategoryMembers. A bit different but it's ok, as it does not make
>>>> much sense to sort categoryMembers with another field than sequenceNum
>>>
>>> Sorting by name?
>>
>> Yes I thought about it, but would need more work (we don't have the
>> internalName in CategoryMember). If we really need it then we should
>> preferably reuse the method I firstly posted in CommonWorker.java but
>> then in ProductWorker. BTW maybe we could have both, not a big deal,
>> just a parameter to add in the service def and a switch on it (if
>> exists) to one or the other implementations.
>
> Create a view for this. It's faster to have the database do all the
> work, then do iterate, and do singleton fetches of each item.
Yes certainly, but apart the 1st roundtrip the Ajax call is fast enough (caching?). I'm not quite sure it would change much things.
>> Note also that this is convenient when you have only a bunch of products
>> per category, clearly more than a dozen begin to be too much... I guess
>> it's why nothing like that exists OOTB... But dependent dropdowns at
>> large are still useful...
>
> We've got a site that has 4000-5000 products per category. All DVD,
> All BluRay. Loop-based lookup/searches are very bad. Including
> handling of VIEW_ALLOW stuff(which is a loop-based system). I haven't
> yet had time to finish/test the singleton query that fixes the
> VIEW_ALLOW performance problem.
Yes, as I said dependent dropdowns are only useful when you have few products by categories.
Jacques
Re: svn commit: r959943 - /ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonWorkers.java
Posted by Adam Heath <do...@brainfood.com>.
Jacques Le Roux wrote:
> From: "Adam Heath" <do...@brainfood.com>
>> jleroux@apache.org wrote:
>>> Author: jleroux
>>> Date: Fri Jul 2 10:32:58 2010
>>> New Revision: 959943
>>>
>>> URL: http://svn.apache.org/viewvc?rev=959943&view=rev
>>> Log:
>>> Revert r959673 on Scott's advice. There is already a
>>> getCategoryMembers. A bit different but it's ok, as it does not make
>>> much sense to sort categoryMembers with another field than sequenceNum
>>
>> Sorting by name?
>
> Yes I thought about it, but would need more work (we don't have the
> internalName in CategoryMember). If we really need it then we should
> preferably reuse the method I firstly posted in CommonWorker.java but
> then in ProductWorker. BTW maybe we could have both, not a big deal,
> just a parameter to add in the service def and a switch on it (if
> exists) to one or the other implementations.
Create a view for this. It's faster to have the database do all the
work, then do iterate, and do singleton fetches of each item.
> Note also that this is convenient when you have only a bunch of products
> per category, clearly more than a dozen begin to be too much... I guess
> it's why nothing like that exists OOTB... But dependent dropdowns at
> large are still useful...
We've got a site that has 4000-5000 products per category. All DVD,
All BluRay. Loop-based lookup/searches are very bad. Including
handling of VIEW_ALLOW stuff(which is a loop-based system). I haven't
yet had time to finish/test the singleton query that fixes the
VIEW_ALLOW performance problem.
Re: svn commit: r959943 - /ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonWorkers.java
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adam Heath" <do...@brainfood.com>
> jleroux@apache.org wrote:
>> Author: jleroux
>> Date: Fri Jul 2 10:32:58 2010
>> New Revision: 959943
>>
>> URL: http://svn.apache.org/viewvc?rev=959943&view=rev
>> Log:
>> Revert r959673 on Scott's advice. There is already a getCategoryMembers. A bit different but it's ok, as it does not make much
>> sense to sort categoryMembers with another field than sequenceNum
>
> Sorting by name?
Yes I thought about it, but would need more work (we don't have the internalName in CategoryMember). If we really need it then we
should preferably reuse the method I firstly posted in CommonWorker.java but then in ProductWorker. BTW maybe we could have both,
not a big deal, just a parameter to add in the service def and a switch on it (if exists) to one or the other implementations.
Note also that this is convenient when you have only a bunch of products per category, clearly more than a dozen begin to be too
much... I guess it's why nothing like that exists OOTB... But dependent dropdowns at large are still useful...
Jacques