Re: Nested attributes for Collection Types
Thank you, all. I've created https://issues.apache.org/jira/browse/OFBIZ-11902 to track this. Best, Girish On Tue, Jul 21, 2020 at 1:14 AM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Thanks Mridul, > > I agree about enhancing existing service definitions > > Jacques > > Le 20/07/2020 à 10:37, Mridul Pathak a écrit : > > Hi Girish, > > > > I think this would be a good improvement to service definition. While it > makes more sense that it would enable creating JSON like schema definitions > it would make service definitions more predictable in general. This > improvement could also be applied to existing service definitions to be > able to expose them as an API in a more sensible way. > > > > Thanks. > > -- > > Mridul Pathak > > > > > >> On 16-Jul-2020, at 5:20 PM, Girish Vasmatkar < > girish.vasmat...@hotwaxsystems.com> wrote: > >> > >> Hey Guys, > >> > >> While working on OpenApi integration as well as GraphQL implementation, > I > >> faced issues on how to automatically document request/response JSON > >> structure for service attributes that were of Collection types (Map, > List > >> etc). > >> > >> For simple types, it is just plain easy but when it comes to Map/Lists, > you > >> have to know what exactly is inside them to be able to convey properly > in > >> the OpenApi schema. > >> > >> I was thinking to may be try to introduce nested attributes in service > >> definition such that if the attribute type is Map/List, you can actually > >> specify what goes inside that attribute - > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> With this change, it becomes possible to generate the schema for the > >> service attribute, Where as if we don't have this option, we can't > possibly > >> indicate what the structure of the "header" key is going to be if it was > >> represented in JSON format. > >> > >> Of course, this change will only help documentation and GraphQL > >> implementation and that there is very little case for it to benefit a > >> general OFBiz service call. > >> > >> Any thoughts or comments on this? Is this too big of a change (impact > wise > >> and not coding perspective) to avoid it and consider something else? Has > >> this been discussed before? > >> > >> Best, > >> Girish > >
Re: Nested attributes for Collection Types
Thanks Mridul, I agree about enhancing existing service definitions Jacques Le 20/07/2020 à 10:37, Mridul Pathak a écrit : Hi Girish, I think this would be a good improvement to service definition. While it makes more sense that it would enable creating JSON like schema definitions it would make service definitions more predictable in general. This improvement could also be applied to existing service definitions to be able to expose them as an API in a more sensible way. Thanks. -- Mridul Pathak On 16-Jul-2020, at 5:20 PM, Girish Vasmatkar wrote: Hey Guys, While working on OpenApi integration as well as GraphQL implementation, I faced issues on how to automatically document request/response JSON structure for service attributes that were of Collection types (Map, List etc). For simple types, it is just plain easy but when it comes to Map/Lists, you have to know what exactly is inside them to be able to convey properly in the OpenApi schema. I was thinking to may be try to introduce nested attributes in service definition such that if the attribute type is Map/List, you can actually specify what goes inside that attribute - With this change, it becomes possible to generate the schema for the service attribute, Where as if we don't have this option, we can't possibly indicate what the structure of the "header" key is going to be if it was represented in JSON format. Of course, this change will only help documentation and GraphQL implementation and that there is very little case for it to benefit a general OFBiz service call. Any thoughts or comments on this? Is this too big of a change (impact wise and not coding perspective) to avoid it and consider something else? Has this been discussed before? Best, Girish
Ordering Decimals
Hi, In OFBiz, OOTB you can order decimals of products. For instance you may want to sell half pizza. That is an user decision. The user may want to allow decimals by store or by product as shown in https://github.com/apache/ofbiz-framework/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/product/product/ProductWorker.java#L1204 We though should not be able to order a part of finished product like "Tiny Chrome Widget" (try 3.5 as mini is 3). You may notice that we have an issue in trunk and R18: see OFBIZ-11899. It works in stable demo and R17 locally. We should set orderDecimalQuantity to false for all products data of FINISHED_GOOD, SERVICE, AGGREGATED, MARKETING_PKG_AUTO, DIGITAL_GOOD, ASSET_USAGE, etc. as can be seen in ProductSeedData.xml. Anyway it should be set on a product basis. I think it's worth to do. Because it's demo data and would show to correctly set things. For a store which sells only not splittable products (which I guess is most of the time when using OFBiz ecommerce) then it's possible to set the same at the store level. What do you think? Jacques
Re: EntityBatchIterator for large data set queries
Thanks Prakhar for this information.
Jacques
Le 20/07/2020 à 10:12, Prakhar Kumar a écrit :
Hello Pawan,
We were getting a hard time dealing with large datasets in our client
project. We were streaming data from MySQL using the FetchSize and
EntityListIterator, which helped us up to some point, but ultimately
struggled with the further increase in data. This is where the batch
processing implementation came to rescue. We incorporated it into our
project and were able to process the data with ease. This implementation
seems to be quite scalable and faster in performance as compared to
streaming. Batch processing was the need of the hour and there we have it
in OFBiz. Thanks, Pawan for your valuable contribution.
On Wed, Jul 1, 2020 at 4:06 PM Pawan Verma
wrote:
Hi Chandan, Jacques
Thanks, for your feedback.
Yes, To solve the problem of heavy entity operations which consumes all the
system memory, we have implemented EntityBatchIterator. Originally designed
for the heavy entity operations.
--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com
On Sun, Jun 28, 2020 at 10:16 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi,
I have not looked into any details but Chandan's advice sounds like a
wise
one to me
Jacques
Le 27/06/2020 à 13:43, Chandan Khandelwal a écrit :
Hello Pawan,
Approach looks good, my only suggestion is to use batch processing only
when we are dealing with large data set, as this method takes a longer
time
compared to the normal method specially on a distributed environment,
which
may negatively impact the performance.
Kind Regards,
Chandan Khandelwal
Senior Manager, Enterprise Software Development
*HotWax Systems*
*Enterprise open source experts*
cell: +91-98934-81076
office: 0731-409-3684
http://www.hotwaxsystems.com
On Fri, Jun 5, 2020 at 4:07 PM Pawan Verma <
pawan.ve...@hotwaxsystems.com>
wrote:
Thanks, Pritam and Scott for the discussion.
I've created Jira OFBIZ-11789 for this improvement and also created a
PR
with the proposed changes.
I request everyone to review the PR and suggest your thought on this.
Thanks!
--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com
On Mon, Jun 1, 2020 at 12:36 PM Pritam Kute <
pritam.k...@hotwaxsystems.com
wrote:
Thanks Scott for your detailed explanation.
The solution looks good to me too. My confusion was with why we are
going
to implement new method if we can achieve that using the current
EntityQuery methods.
+1 for adding queryBatchIterator() to EntityQuery.
Kind Regards,
--
Pritam Kute
On Thu, May 28, 2020 at 6:32 AM Scott Gray <
scott.g...@hotwaxsystems.com
wrote:
Hi Pritam,
I'm not sure about PostgreSQL or Derby but I know with MySQL that
using a
cursor doesn't really work. You have to set the result set to
TYPE_FORWARD_ONLY and CONCUR_READ_ONLY and also set the fetch size
to
INTEGER.MIN_VALUE. Only then will the driver stream the results and
even
then, you may not execute any other SQL commands on the connection
until
you have fully read or closed the resultset.
So if an EntityListIterator doesn't really conserve memory, then you
need
to take a paging query approach such as this:
EntityQuery query =
EntityQuery.use(delegator).from("SomeTable").limit(100)
List results = null
while (!(results = query.queryList()).isEmpty()) {
for (value : results) {
// do something with each value
}
query.offset(query.getOffset() + query.getLimit())
}
Or with the proposed EntityBatchIterator:
Iterator query =
EntityQuery.use(delegator).from("SomeTable").limit(100).queryBatchIterator()
while (iterator.hasNext()) {
result = iterator.next()
// do something with each value
}
I guess an alternative approach would be to implement something
similar
within the EntityListIterator and perhaps a flag to turn it off or
on
depending on which database is being used and how well it supports
iterating over results without loading the entire resultset into
memory.
Regards
Scott
On Sat, 23 May 2020 at 20:59, Pritam Kute <
pritam.k...@hotwaxsystems.com
wrote:
Hello Pawan,
I just had a look into the EntityQuery.queryIterator() method and
looks
like we can achieve that by using fetchSize(), fowardOnly(),
cursorScrollInsensitive(), cursorScrollSensitive() and offset()
methods
in
EntityQuery class. Let me know if I am missing anything.
It will be good if you can post a pseudo code or something here so
that
we
could get an understanding of the exact design which you have in
your
mind.
Kind Regards,
--
Pritam Kute
On Thu, May 21, 2020 at 7:41 PM Pawan Verma <
pawan.ve...@hotwaxsystems.com
wrote:
Hello Devs,
While working on the large database we have figured out that very
large
queries consume all memory and crash ofbiz(because queryIterator()
doesn't
really work, it's no different from
Re: Documentation "issues"
Hi, I think it's great that you are migration your docs to AsciiDoc. What are you using to publish them? We've been working on doing a similar process in Apache James. We decided to use Antora for publishing the content which is pretty great so far. We haven't finished our process. I've managed to make the automated build and the next goal is to work on the content and structure. If you are interested, here are some links: * https://github.com/apache/james-site/ - repo to build the documentation website - includes gradle tasks to build the theme and run antora. * Jenkinsfile is used to publish the staged website to https://james.staged.apache.org/main/3.5/index.html * https://issues.apache.org/jira/browse/JAMES-3226 Jira issue to track the progress La 20.07.2020 11:54, Olivier Heintz a scris: Thanks Jacques, for this list, I will finish the plugins docbook migration to asciidoc and I will continue with these JIRA, with a first step to be sure to migrate all old format to the new one. This list is a good road to clean before doing some new doc. Thanks Olivier Le 17/07/2020 à 09:46, Jacques Le Roux a écrit : Hi All, Olivier, Again Olivier, I must say I'm so glad that you took the documentation challenge in hands. That's very promising for the future of the project. Thanks for your work! At this stage I'd like to clean the situation as much as possible. It's not about your work, but about all that we have left behind us. It's difficult to figure out what the situation really is. There are few minor things and some others more systemic. What are your thought about them? Take your time ;) Among the minor issues: I think we should begin to close issues like: OFBIZ-6644: This is deprecated with its sub-tasks OFBIZ-11893: Trivial issues I collected before forgetting them. You might found more. https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML: This is now broken. I guess after you removed some files referenced by documents in /plugins/cmssite/documents Related with OFBIZ-11364 I guess. OFBIZ-9926 should be closed. OFBIZ-6243: Should we take the burden of migrating the existing README.md? I don't think so. I'd like to remove them with the related wiki pages, like: https://cwiki.apache.org/confluence/display/OFBENDUSER/Financial+Accounting+and+Reporting All that is mostly deprecated and redundant. Among the more serious ones: = OFBIZ-10285: What are your thoughts about this one (sorry not enough time to dig in)? It's clearly time to prune the sub-tasks, I mean close them if possible, like: OFBIZ-10251 OFBIZ-10255 OFBIZ-11364 etc. Also we need to update, actually mainly prune, the wiki, there is too much deprecated and MISLEADING documentation there! A bit of pontification :): One thing I learned is that it's hard to maintain a documentation. Because things evolve and are not always related to each other (like code). So we should restrain ourselves to refer to things that may disappear or change in the future. If not possible we need to generalise them as much as possible. An example is OFBIZ-6243. Jacques -- Eugen Stan +40720 898 747 / netdava.com
Re: EntityBatchIterator for large data set queries
Hi Prakhar,
Glad to know that this implementation helps you. Thanks for sharing details
:)
--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com
On Mon, Jul 20, 2020 at 1:42 PM Prakhar Kumar <
prakhar.ku...@hotwaxsystems.com> wrote:
> Hello Pawan,
>
> We were getting a hard time dealing with large datasets in our client
> project. We were streaming data from MySQL using the FetchSize and
> EntityListIterator, which helped us up to some point, but ultimately
> struggled with the further increase in data. This is where the batch
> processing implementation came to rescue. We incorporated it into our
> project and were able to process the data with ease. This implementation
> seems to be quite scalable and faster in performance as compared to
> streaming. Batch processing was the need of the hour and there we have it
> in OFBiz. Thanks, Pawan for your valuable contribution.
>
> On Wed, Jul 1, 2020 at 4:06 PM Pawan Verma
> wrote:
>
> > Hi Chandan, Jacques
> >
> > Thanks, for your feedback.
> >
> > Yes, To solve the problem of heavy entity operations which consumes all
> the
> > system memory, we have implemented EntityBatchIterator. Originally
> designed
> > for the heavy entity operations.
> > --
> > Thanks & Regards
> > Pawan Verma
> > Technical Consultant
> > *HotWax Systems*
> > *Enterprise open source experts*
> > http://www.hotwaxsystems.com
> >
> >
> > On Sun, Jun 28, 2020 at 10:16 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> > > Hi,
> > >
> > > I have not looked into any details but Chandan's advice sounds like a
> > wise
> > > one to me
> > >
> > > Jacques
> > >
> > > Le 27/06/2020 à 13:43, Chandan Khandelwal a écrit :
> > > > Hello Pawan,
> > > >
> > > > Approach looks good, my only suggestion is to use batch processing
> only
> > > > when we are dealing with large data set, as this method takes a
> longer
> > > time
> > > > compared to the normal method specially on a distributed environment,
> > > which
> > > > may negatively impact the performance.
> > > >
> > > > Kind Regards,
> > > > Chandan Khandelwal
> > > > Senior Manager, Enterprise Software Development
> > > >
> > > > *HotWax Systems*
> > > > *Enterprise open source experts*
> > > > cell: +91-98934-81076
> > > > office: 0731-409-3684
> > > > http://www.hotwaxsystems.com
> > > >
> > > >
> > > > On Fri, Jun 5, 2020 at 4:07 PM Pawan Verma <
> > > pawan.ve...@hotwaxsystems.com>
> > > > wrote:
> > > >
> > > >> Thanks, Pritam and Scott for the discussion.
> > > >>
> > > >> I've created Jira OFBIZ-11789 for this improvement and also created
> a
> > PR
> > > >> with the proposed changes.
> > > >>
> > > >> I request everyone to review the PR and suggest your thought on
> this.
> > > >> Thanks!
> > > >> --
> > > >> Thanks & Regards
> > > >> Pawan Verma
> > > >> Technical Consultant
> > > >> *HotWax Systems*
> > > >> *Enterprise open source experts*
> > > >> http://www.hotwaxsystems.com
> > > >>
> > > >>
> > > >> On Mon, Jun 1, 2020 at 12:36 PM Pritam Kute <
> > > pritam.k...@hotwaxsystems.com
> > > >> wrote:
> > > >>
> > > >>> Thanks Scott for your detailed explanation.
> > > >>>
> > > >>> The solution looks good to me too. My confusion was with why we are
> > > going
> > > >>> to implement new method if we can achieve that using the current
> > > >>> EntityQuery methods.
> > > >>>
> > > >>> +1 for adding queryBatchIterator() to EntityQuery.
> > > >>>
> > > >>> Kind Regards,
> > > >>> --
> > > >>> Pritam Kute
> > > >>>
> > > >>>
> > > >>> On Thu, May 28, 2020 at 6:32 AM Scott Gray <
> > > scott.g...@hotwaxsystems.com
> > > >>>
> > > >>> wrote:
> > > >>>
> > > Hi Pritam,
> > >
> > > I'm not sure about PostgreSQL or Derby but I know with MySQL that
> > > >> using a
> > > cursor doesn't really work. You have to set the result set to
> > > TYPE_FORWARD_ONLY and CONCUR_READ_ONLY and also set the fetch size
> > to
> > > INTEGER.MIN_VALUE. Only then will the driver stream the results
> and
> > > >> even
> > > then, you may not execute any other SQL commands on the connection
> > > >> until
> > > you have fully read or closed the resultset.
> > >
> > > So if an EntityListIterator doesn't really conserve memory, then
> you
> > > >> need
> > > to take a paging query approach such as this:
> > > EntityQuery query =
> > > >>> EntityQuery.use(delegator).from("SomeTable").limit(100)
> > > List results = null
> > > while (!(results = query.queryList()).isEmpty()) {
> > > for (value : results) {
> > > // do something with each value
> > > }
> > > query.offset(query.getOffset() + query.getLimit())
> > > }
> > >
> > > Or with the proposed EntityBatchIterator:
> > > Iterator query =
> > >
> > >
> > > >>
> > >
> >
> EntityQuery.use(delegator).from("SomeTable").limit(100).queryBatchIterator()
> > > while (iterator.hasNext()) {
> >
Re: Documentation "issues"
Thanks Jacques, for this list, I will finish the plugins docbook migration to asciidoc and I will continue with these JIRA, with a first step to be sure to migrate all old format to the new one. This list is a good road to clean before doing some new doc. Thanks Olivier Le 17/07/2020 à 09:46, Jacques Le Roux a écrit : > Hi All, Olivier, > > Again Olivier, I must say I'm so glad that you took the documentation > challenge in hands. That's very promising for the future of the project. > Thanks > for your work! > > At this stage I'd like to clean the situation as much as possible. It's not > about your work, but about all that we have left behind us. It's difficult > to figure out what the situation really is. > > There are few minor things and some others more systemic. What are your > thought about them? Take your time ;) > > Among the minor issues: > > > I think we should begin to close issues like: > > OFBIZ-6644: > This is deprecated with its sub-tasks > > OFBIZ-11893: > Trivial issues I collected before forgetting them. You might found more. > > https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML: > This is now broken. I guess after you removed some files referenced by > documents in /plugins/cmssite/documents > Related with OFBIZ-11364 I guess. > OFBIZ-9926 should be closed. > > OFBIZ-6243: > Should we take the burden of migrating the existing README.md? > I don't think so. I'd like to remove them with the related wiki pages, like: > https://cwiki.apache.org/confluence/display/OFBENDUSER/Financial+Accounting+and+Reporting > All that is mostly deprecated and redundant. > > Among the more serious ones: > = > > OFBIZ-10285: > What are your thoughts about this one (sorry not enough time to dig in)? > It's clearly time to prune the sub-tasks, I mean close them if possible, like: > OFBIZ-10251 > OFBIZ-10255 > OFBIZ-11364 > etc. > > Also we need to update, actually mainly prune, the wiki, there is too much > deprecated and MISLEADING documentation there! > > A bit of pontification :): > > One thing I learned is that it's hard to maintain a documentation. Because > things evolve and are not always related to each other (like code). > So we should restrain ourselves to refer to things that may disappear or > change in the future. If not possible we need to generalise them as much as > possible. > An example is OFBIZ-6243. > > Jacques >
Re: Nested attributes for Collection Types
Hi Girish, I think this would be a good improvement to service definition. While it makes more sense that it would enable creating JSON like schema definitions it would make service definitions more predictable in general. This improvement could also be applied to existing service definitions to be able to expose them as an API in a more sensible way. Thanks. -- Mridul Pathak > On 16-Jul-2020, at 5:20 PM, Girish Vasmatkar > wrote: > > Hey Guys, > > While working on OpenApi integration as well as GraphQL implementation, I > faced issues on how to automatically document request/response JSON > structure for service attributes that were of Collection types (Map, List > etc). > > For simple types, it is just plain easy but when it comes to Map/Lists, you > have to know what exactly is inside them to be able to convey properly in > the OpenApi schema. > > I was thinking to may be try to introduce nested attributes in service > definition such that if the attribute type is Map/List, you can actually > specify what goes inside that attribute - > > > > > > > > > > > > With this change, it becomes possible to generate the schema for the > service attribute, Where as if we don't have this option, we can't possibly > indicate what the structure of the "header" key is going to be if it was > represented in JSON format. > > Of course, this change will only help documentation and GraphQL > implementation and that there is very little case for it to benefit a > general OFBiz service call. > > Any thoughts or comments on this? Is this too big of a change (impact wise > and not coding perspective) to avoid it and consider something else? Has > this been discussed before? > > Best, > Girish
Re: EntityBatchIterator for large data set queries
Hello Pawan,
We were getting a hard time dealing with large datasets in our client
project. We were streaming data from MySQL using the FetchSize and
EntityListIterator, which helped us up to some point, but ultimately
struggled with the further increase in data. This is where the batch
processing implementation came to rescue. We incorporated it into our
project and were able to process the data with ease. This implementation
seems to be quite scalable and faster in performance as compared to
streaming. Batch processing was the need of the hour and there we have it
in OFBiz. Thanks, Pawan for your valuable contribution.
On Wed, Jul 1, 2020 at 4:06 PM Pawan Verma
wrote:
> Hi Chandan, Jacques
>
> Thanks, for your feedback.
>
> Yes, To solve the problem of heavy entity operations which consumes all the
> system memory, we have implemented EntityBatchIterator. Originally designed
> for the heavy entity operations.
> --
> Thanks & Regards
> Pawan Verma
> Technical Consultant
> *HotWax Systems*
> *Enterprise open source experts*
> http://www.hotwaxsystems.com
>
>
> On Sun, Jun 28, 2020 at 10:16 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Hi,
> >
> > I have not looked into any details but Chandan's advice sounds like a
> wise
> > one to me
> >
> > Jacques
> >
> > Le 27/06/2020 à 13:43, Chandan Khandelwal a écrit :
> > > Hello Pawan,
> > >
> > > Approach looks good, my only suggestion is to use batch processing only
> > > when we are dealing with large data set, as this method takes a longer
> > time
> > > compared to the normal method specially on a distributed environment,
> > which
> > > may negatively impact the performance.
> > >
> > > Kind Regards,
> > > Chandan Khandelwal
> > > Senior Manager, Enterprise Software Development
> > >
> > > *HotWax Systems*
> > > *Enterprise open source experts*
> > > cell: +91-98934-81076
> > > office: 0731-409-3684
> > > http://www.hotwaxsystems.com
> > >
> > >
> > > On Fri, Jun 5, 2020 at 4:07 PM Pawan Verma <
> > pawan.ve...@hotwaxsystems.com>
> > > wrote:
> > >
> > >> Thanks, Pritam and Scott for the discussion.
> > >>
> > >> I've created Jira OFBIZ-11789 for this improvement and also created a
> PR
> > >> with the proposed changes.
> > >>
> > >> I request everyone to review the PR and suggest your thought on this.
> > >> Thanks!
> > >> --
> > >> Thanks & Regards
> > >> Pawan Verma
> > >> Technical Consultant
> > >> *HotWax Systems*
> > >> *Enterprise open source experts*
> > >> http://www.hotwaxsystems.com
> > >>
> > >>
> > >> On Mon, Jun 1, 2020 at 12:36 PM Pritam Kute <
> > pritam.k...@hotwaxsystems.com
> > >> wrote:
> > >>
> > >>> Thanks Scott for your detailed explanation.
> > >>>
> > >>> The solution looks good to me too. My confusion was with why we are
> > going
> > >>> to implement new method if we can achieve that using the current
> > >>> EntityQuery methods.
> > >>>
> > >>> +1 for adding queryBatchIterator() to EntityQuery.
> > >>>
> > >>> Kind Regards,
> > >>> --
> > >>> Pritam Kute
> > >>>
> > >>>
> > >>> On Thu, May 28, 2020 at 6:32 AM Scott Gray <
> > scott.g...@hotwaxsystems.com
> > >>>
> > >>> wrote:
> > >>>
> > Hi Pritam,
> >
> > I'm not sure about PostgreSQL or Derby but I know with MySQL that
> > >> using a
> > cursor doesn't really work. You have to set the result set to
> > TYPE_FORWARD_ONLY and CONCUR_READ_ONLY and also set the fetch size
> to
> > INTEGER.MIN_VALUE. Only then will the driver stream the results and
> > >> even
> > then, you may not execute any other SQL commands on the connection
> > >> until
> > you have fully read or closed the resultset.
> >
> > So if an EntityListIterator doesn't really conserve memory, then you
> > >> need
> > to take a paging query approach such as this:
> > EntityQuery query =
> > >>> EntityQuery.use(delegator).from("SomeTable").limit(100)
> > List results = null
> > while (!(results = query.queryList()).isEmpty()) {
> > for (value : results) {
> > // do something with each value
> > }
> > query.offset(query.getOffset() + query.getLimit())
> > }
> >
> > Or with the proposed EntityBatchIterator:
> > Iterator query =
> >
> >
> > >>
> >
> EntityQuery.use(delegator).from("SomeTable").limit(100).queryBatchIterator()
> > while (iterator.hasNext()) {
> > result = iterator.next()
> > // do something with each value
> > }
> >
> > I guess an alternative approach would be to implement something
> > similar
> > within the EntityListIterator and perhaps a flag to turn it off or
> on
> > depending on which database is being used and how well it supports
> > iterating over results without loading the entire resultset into
> > >> memory.
> > Regards
> > Scott
> >
> >
> >
> > On Sat, 23 May 2020 at 20:59, Pritam Kute <
> > >> pritam.k...@hotwaxsystems.com
> > wrote:
> >
> > >
