1

Would it be possible to add the last_access_date field to the shallow_user object? I presume this corresponds to the seen field when visiting someone's profile.

My reasoning is that it saves the extra API call to the full user object just to retrieve this one field. This of course is in the context of doing /search (or similar) queries.

Improve this question
6
  • 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?
    – Jonathan.
    Commented Feb 1, 2012 at 18:00
  • @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?
    – Marvin Pinto
    Commented Feb 1, 2012 at 18:03
  • 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.
    – Jonathan.
    Commented Feb 1, 2012 at 18:09
  • @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.
    – Marvin Pinto
    Commented Feb 1, 2012 at 18:17
  • @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 :)
    – Marvin Pinto
    Commented Feb 1, 2012 at 18:17
  • 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
    – Jonathan.
    Commented Feb 1, 2012 at 18:44

1 Answer 1

Reset to default
0

The shallow_user type contains only fields that are "fast" to fetch, as it's always returned as a member of other (potentially expensive to fetch) types.

Accordingly, we can't add any fields to shallow_user that aren't "fast" and in generally, won't add things that aren't really commonly needed. I don't think the last_access_date is required often enough to take the perf hit.

As to the reason for separate user and shallow_user types, if we didn't have them it'd be far too easy to craft queries that include too much of users to be reasonable to execute (trivial example, /search with a tag and all user fields would hit something like 5 tables in the cache-miss case on top of actually running the search).

We could use filters I suppose, but we'd be in an awkward situation where certain combinations of fields would have to be forbidden. Simpler to just have a different type, at least in my opinion.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .