| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
| World Community Grid Forums
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 16
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Got a massive problem... too many records to handle being returned, 28000 and counting, so decided to revisit the API filter options which says:
----------------------------------------Optional parameters are (can be combined): What I wanted to achieve was primary sort on Received Time, then secondary filter on the Modtime, on or after, with the latter part of the URL formatted as follows, the Modtime seconds per unix at start of this statistics period which is 1481500800 aka 161212 at 00:00:00 &format=xml&limit=250&offset=0&ServerState=5&SortBy=ReceivedTime&=ModTime=1481500800 What is being returned as top record with application of an offset of 250 is a result with a modtime from before the last modified on or after this time ... the query response does not want to be convinced to adhere to my requirements <?xml version="1.0" encoding="UTF-8" ?> - <ResultsStatus> <ResultsAvailable>860</ResultsAvailable> <ResultsReturned>250</ResultsReturned> <Offset>250</Offset> - <Result> <AppName>fahv</AppName> <ClaimedCredit>17.04168537594135</ClaimedCredit> <CpuTime>1.1776388883590698</CpuTime> <ElapsedTime>1.1856697797775269</ElapsedTime> <ExitStatus>0</ExitStatus> <GrantedCredit>17.04168537594135</GrantedCredit> <DeviceId>3483292</DeviceId> <DeviceName>uhuh</DeviceName> <ModTime>1481498153</ModTime> <Name>FAHV_1000137_4xfx_P1_Rigid_4525_0</Name> <Outcome>1</Outcome> <ReceivedTime>2016-12-11T23:15:48</ReceivedTime> <ReportDeadline>2016-12-21T10:30:35</ReportDeadline> <SentTime>2016-12-11T10:30:35</SentTime> <ServerState>5</ServerState> <ValidateState>1</ValidateState> <FileDeleteState>2</FileDeleteState> </Result> Is this a bug, or is it me, the construction of the URL query (I hope so, as that's quickly adjustable). Many thanks in advance (fellow API utilizers too if they know the answer) edit: Questionmark in title of course [Edit 1 times, last edit by Former Member at Dec 12, 2016 2:33:07 PM] |
||
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1413 Status: Offline Project Badges:
|
&format=xml&limit=250&offset=0&ServerState=5&SortBy=ReceivedTime&= ModTime=1481500800 I think the red = sign is too much, but I'm surely not an API-expert; even not a API-user. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Thanks for that CP... don't know why I typed the extra = , so verified for the new period, from the top, no offset this time
&format=xml&limit=250&offset=0&ServerState=5&SortBy=ReceivedTime&Modtime=1481587570 and got records earlier than the desired ModTime. <?xml version="1.0" encoding="UTF-8" ?> - <ResultsStatus> <ResultsAvailable>30751</ResultsAvailable> <ResultsReturned>250</ResultsReturned> <Offset>0</Offset> - <Result> <AppName>mcm1</AppName> <ClaimedCredit>114.5433955084077</ClaimedCredit> <CpuTime>5.01069450378418</CpuTime> <ElapsedTime>5.090649604797363</ElapsedTime> <ExitStatus>0</ExitStatus> <GrantedCredit>0.0</GrantedCredit> <DeviceId>3483292</DeviceId> <DeviceName>uhuh</DeviceName> <ModTime>1481554099</ModTime> <Name>MCM1_0128450_9796_1</Name> <Outcome>1</Outcome> <ReceivedTime>2016-12-12T14:48:19</ReceivedTime> <ReportDeadline>2016-12-18T21:35:07</ReportDeadline> <SentTime>2016-12-11T21:35:07</SentTime> <ServerState>5</ServerState> <ValidateState>0</ValidateState> <FileDeleteState>0</FileDeleteState> </Result> Would the filter work, there'd be need for pulling over 11,500 records for the last period instead of now > 30K with Serverstate 5, representing a massive improvement in execution time. |
||
|
|
foxfire
Advanced Cruncher United States Joined: Sep 1, 2007 Post Count: 121 Status: Offline Project Badges:
|
I'm seeing the same as you. Asked to pull results with mod time of 1481503715 or greater (no sort). Got 2208 results returned of which 693 had mod time older than requested. In my pull the older results didn't start until record 756 (relative to 1).
----------------------------------------URL: https:// secure.worldcommunitygrid.org/api/members/foxfire/results?code=my_ver_code&ModTime=1481503715&Offset=x&limit=250&format=json I start my offset at 0 and pull 250 at a time.. ![]() |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Bump @ Techs. This bug is stalling the development progression.
|
||
|
|
ErikaT
Former World Community Grid Admin USA Joined: Apr 27, 2009 Post Count: 912 Status: Offline Project Badges:
|
Bump @ Techs. This bug is stalling the development progression. Hi Sek,I have notified the team. Thank you in advance for your patience with response time ErikaT |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges:
|
We have a deployed a change that should resolve this issue. If you could test with your apps and let us know that would be great!
|
||
|
|
wujj123456
Cruncher Joined: Jun 9, 2010 Post Count: 40 Status: Offline Project Badges:
|
We have a deployed a change that should resolve this issue. If you could test with your apps and let us know that would be great! Did the update break some filters? I usually query with ValidateState=1 and now it just returns 500. Removing ValidateState=1 works fine. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
We have a deployed a change that should resolve this issue. If you could test with your apps and let us know that would be great! The combination of Offset & Limit & ServerState & ReceivedTime & ModTime works a treat now [:ThumbsUpSmiley]. Adding (small) validationstate= or proper ValidationState= seems ineffective with any of the VS codes, 0, 1, 2, 4 or kicks out an error, noting that if modtime (small) is used it does not work but if ModTime (Proper) is used, it works i.e. the call seems to be case sensitive (superficial testing). |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
BTW, may have asked about this before but an inverse filter would also be great e.g. ValidationState<>0 or Outcome<>7 (who's interested in pulling aborted tasks with zero runtime, which brings me to just pulling ServerState=5 and CPUTime>0, as an additional filter tag, or CPUTime=1 meaning has runtime ;?)
From the creative commons department, and only if you have the hour spare to be creative. ;P) |
||
|
|
|