Re: [google-appengine] Re: In queries and cursors limitation
The suggestion looks good. thanks.
On Thu, Jan 19, 2017 at 1:00 AM, Jason Collins
wrote:
> Add a new field called, e.g, queryableStatus that is a list of strings.
> Then pre-compute your query logic so that you only need an equality filter.
>
> E.g, when saving the entity (warning: pseudocode ahead):
>
> if status in ['PAID', 'PARTIALLY_PAID']:
> invoice.queryableStatus.append('PAID_OR_PARTIALLY_PAID')
> # you can have all sorts of logic combinations and tags appended, if you
> need them
> invoice.save()
>
>
> Then. when you query, you can use an equality:
>
> ofy.query(Invoice.class).filter("status =", ['PAID_OR_PARTIALLY_PAID']).
> limit(100).list()
>
>
> This will let the cursor work as expected.
>
>
> Of course, you'll have to one-time update all your existing invoices. And
> you'll need to one-time update all your existing invoices whenever your
> QueryableStatus logic changes.
>
>
>
> On Tuesday, 17 January 2017 20:38:53 UTC-8, Rajesh Gupta wrote:
>>
>> I have the following
>>
>> Public class Invoice {
>> @Id Long id
>>Key partyKey;
>>Status status
>> }
>>
>> enum Status {
>> PAID, PARTIAL_PAID, PENDING, DRAFT
>> }
>>
>> I want to find all invoices with Status = PAID, PARTIAL_PAID, so I do the
>> IN query
>>
>> ofy.query(Invoice.class).filter("status in", [PAID,
>> PARTIAL_PAID]).limit(100).list()
>>
>> However, then, if I want the next 100, the cursor will not work because
>> of IN query
>>
>> What are the alternate solutions or schemas'.
>>
>> --
>> Regards,
>> Rajesh
>> *www.VeersoftSolutions.com *
>> *www.GainERP.com *
>> *Accounting/Inventory/Orders/Sales/Purchase on Google Cloud Platform and
>> Mobile*
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-appengine.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-appengine/c194cda0-2fdb-4f2e-8b11-
> 1b641cd7de82%40googlegroups.com
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Regards,
Rajesh
*www.VeersoftSolutions.com *
*www.GainERP.com *
*Accounting/Inventory/Orders/Sales/Purchase on Google Cloud Platform and
Mobile*
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-appengine/CA%2BS7ijY4Fx-BOYQz5N9MiY1C-Ccximggs%2B%2BE8cb9v2oszsQnbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: In queries and cursors limitation
Add a new field called, e.g, queryableStatus that is a list of strings.
Then pre-compute your query logic so that you only need an equality filter.
E.g, when saving the entity (warning: pseudocode ahead):
if status in ['PAID', 'PARTIALLY_PAID']:
invoice.queryableStatus.append('PAID_OR_PARTIALLY_PAID')
# you can have all sorts of logic combinations and tags appended, if you
need them
invoice.save()
Then. when you query, you can use an equality:
ofy.query(Invoice.class).filter("status =",
['PAID_OR_PARTIALLY_PAID']).limit(100).list()
This will let the cursor work as expected.
Of course, you'll have to one-time update all your existing invoices. And
you'll need to one-time update all your existing invoices whenever your
QueryableStatus logic changes.
On Tuesday, 17 January 2017 20:38:53 UTC-8, Rajesh Gupta wrote:
>
> I have the following
>
> Public class Invoice {
> @Id Long id
>Key partyKey;
>Status status
> }
>
> enum Status {
> PAID, PARTIAL_PAID, PENDING, DRAFT
> }
>
> I want to find all invoices with Status = PAID, PARTIAL_PAID, so I do the
> IN query
>
> ofy.query(Invoice.class).filter("status in", [PAID,
> PARTIAL_PAID]).limit(100).list()
>
> However, then, if I want the next 100, the cursor will not work because of
> IN query
>
> What are the alternate solutions or schemas'.
>
> --
> Regards,
> Rajesh
> *www.VeersoftSolutions.com *
> *www.GainERP.com *
> *Accounting/Inventory/Orders/Sales/Purchase on Google Cloud Platform and
> Mobile*
>
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-appengine/c194cda0-2fdb-4f2e-8b11-1b641cd7de82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: IN queries
Good thing I didn't rewrite my code before asking :-). I see the asynctools Jason posted, but I would be looking for a join (in the thread sense) that allows continued processing once all the results are back. On Fri, Sep 4, 2009 at 8:44 AM, Nick Johnson (Google) wrote: > Hi Jeff, > IN queries are split up into multiple basic queries entirely in user code, > so there's no latency or other benefit to using them over doing multiple > queries yourself - it's just for convenience. In future, though, the > MultiQuery interface may be extended to do its queries in parallel. > -Nick > > On Fri, Sep 4, 2009 at 4:30 PM, Jeff Enderwick > wrote: >> >> I read somewhere that IN queries are processed serially by the >> datastore. GOOGers, what is a rough rule-of-thumb on the benefit of >> using IN? For example, if the base RT latency for anything with the >> datastore is Nms, then could guesstimate that using N for a list of 3 >> is not a huge latency win, but using IN for 10 is. Does using IN >> substantially cut down on the api_cpu_ms used vs sequential queries? >> >> > > > > -- > Nick Johnson, Developer Programs Engineer, App Engine > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: IN queries
In the meantime, you can use http://code.google.com/p/asynctools/ to kick off parallel queries. It doesn't (yet) directly support MultiQuery, so you'll need to rewrite your IN queries as a set of equality queries. j On Sep 4, 9:44 am, "Nick Johnson (Google)" wrote: > Hi Jeff, > IN queries are split up into multiple basic queries entirely in user code, > so there's no latency or other benefit to using them over doing multiple > queries yourself - it's just for convenience. In future, though, the > MultiQuery interface may be extended to do its queries in parallel. > > -Nick > > On Fri, Sep 4, 2009 at 4:30 PM, Jeff Enderwick > wrote: > > > > > I read somewhere that IN queries are processed serially by the > > datastore. GOOGers, what is a rough rule-of-thumb on the benefit of > > using IN? For example, if the base RT latency for anything with the > > datastore is Nms, then could guesstimate that using N for a list of 3 > > is not a huge latency win, but using IN for 10 is. Does using IN > > substantially cut down on the api_cpu_ms used vs sequential queries? > > -- > Nick Johnson, Developer Programs Engineer, App Engine --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: IN queries
Hi Jeff, IN queries are split up into multiple basic queries entirely in user code, so there's no latency or other benefit to using them over doing multiple queries yourself - it's just for convenience. In future, though, the MultiQuery interface may be extended to do its queries in parallel. -Nick On Fri, Sep 4, 2009 at 4:30 PM, Jeff Enderwick wrote: > > I read somewhere that IN queries are processed serially by the > datastore. GOOGers, what is a rough rule-of-thumb on the benefit of > using IN? For example, if the base RT latency for anything with the > datastore is Nms, then could guesstimate that using N for a list of 3 > is not a huge latency win, but using IN for 10 is. Does using IN > substantially cut down on the api_cpu_ms used vs sequential queries? > > > > -- Nick Johnson, Developer Programs Engineer, App Engine --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
