So,
I think we are misunderstanding each other... and I still do not see why its not that simple.
I DO NOT want a Global read or unread setting.. I want to call the api call once per user, which we could then cache etc.
I completely understand your API example, we looked at doing something similar, but its to performance heavy.
Essentially all we want to do is able to call:
Select * from messages where user_context.read - false and board.id='boardid'
Now if this was a straight SQL query on a database that would be an even easier task. So for me the complexity is simply exposing the ability via the API to use a field that the collection already has as a Liql Constraint
Hopefully that has clarified why a) this shouldn't be that complicated and b) DougS could you help me identify the person in Lithium who owns the API roadmap so I can push this up the development flagpole?
Some how looking at whats happening with idea's of late doesn't fill me with confidence that filing another idea will make this happen.
Most LiQL calls that look up messages go to a search index that stores various fields about the message, and does not store per-user values for any fields.
We could send a query like you are making to the database instead, but we only store read state per user per board (we can't get you all of the read/unread messages for a category or the community). We would not be able to filter the query any further (by adding additional constraints).
So if we add support for doing a LiQL query that looks up unread messages for the calling user, we have to support special logic: if you use the user_context.read constraint, you must also use the board.id constraint, and cannot use any additional constraints (if those 2 constraints are passed we will query the database instead of hitting the search index) -- we'll need to enforce that and return an error if you use the user_context.read constraint and either use other constraints, or if you don't use the board.id constraint.
I hope that clarifies things a bit with respect to the complexity this adds. I still agree that it's probably better to do it this way then implementing logic that checks results for read/unread state and does additional queries to fill in the result set.
-Doug
