Timeline for Add last_access_date field to the shallow_user object
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 1, 2012 at 20:39 | vote | accept | Marvin Pinto | ||
| Feb 1, 2012 at 20:37 | answer | added | Kevin Montrose | timeline score: 0 | |
| Feb 1, 2012 at 20:27 | history | edited | Kevin Montrose |
edited tags
|
|
| Feb 1, 2012 at 18:44 | comment | added | Jonathan. | I was going to something I thought I heard, that the filters were more integrated, and only the fields checked are pulled (I think it was something about the total field being expensive on their side and thats why it is disabled in default filter, and been replaced with has_more), but I don't know if thats true, so my comments are made on the assumption that it's true, if it's not then I completely understand the point of shallow_user and my comments are invalid | |
| Feb 1, 2012 at 18:17 | comment | added | Marvin Pinto |
@Jonathan. From what I understand of filters (in this context), you enable or disable only what you need, but on the backend, all those objects are pulled no matter what - filters only prevent them from being sent to you (thus conserving bandwidth). That's probably the reason they went with the shallow_user object in the first place. Then again, this could all be heresay :)
|
|
| Feb 1, 2012 at 18:17 | comment | added | Marvin Pinto |
@Jonathan. Right, you meant if a /search query returned the full user object - yeah I missed that part. I don't think what you're asking for will be feasible. To be honest, I don't see them even adding the field I wanted. I don't know how their stuff is structured in the backend, but I can imagine that it will be very expensive to return a full user object with each (relevant) query.
|
|
| Feb 1, 2012 at 18:09 | comment | added | Jonathan. |
With filters you could choose which field you want and don't want from the full user object. So if the /search query return user objects. Eg, You can choose that you want the accept_rate and last_access_date fields but not the reputation field. So rather than asking for fields to copied from the user object to shallow_user you can just untick the fields you don't want. The same also goes for network_user.
|
|
| Feb 1, 2012 at 18:03 | comment | added | Marvin Pinto |
@Jonathan. There's a good chance I've missed the point so bare with me :) Ignore the shallow_user object for now. How would I retrieve the full user object in a /search query using filters?
|
|
| Feb 1, 2012 at 18:00 | comment | added | Jonathan. |
This is the problem with shallow_user there will always be a field wanted from user. This is exactly the problem filters solve. Please Kevin can we get rid of the shallow_user?
|
|
| Feb 1, 2012 at 17:01 | history | asked | Marvin Pinto | CC BY-SA 3.0 |