Async Key Operations

[Simie]

I'm working on a plugin which uses post keys to provide per-post ratings.

Scenario: 
- User A loads page, reads thread, triggers action which increments post key.
- User B loaded the page before the first user updated the key, triggers an action which increments post key

Result:
User A's increment is not counted.

Is there a way of retrieving the latest value of a key before setting the new value?

Tagging some folks who might know Peter Chris Xikeon Chris Wormopolis Todge

[Peter]

Unfortunately no, as we aren't allowed to perform additional AJAX requests to update the key data before setting it.

Each "set" request overrides the key data, so it becomes an issue when a key is shared amongst staff and members (i.e like my Rate Threads plugin). Obviously on a forum that isn't too active, it probably won't be an issue.

[Simie]

May 14, 2013 16:51:25 GMT -8 Peter said:

Unfortunately no, as we aren't allowed to perform additional AJAX requests to update the key data before setting it.

Each "set" request overrides the key data, so it becomes an issue when a key is shared amongst staff and members (i.e like my Rate Threads plugin). Obviously on a forum that isn't too active, it probably won't be an issue.

That's what I feared. The additional server load of a fetch before set shouldn't be that great, as it's still caused by a user action. Do you think folks at the top would be open to implementing something like this?

[Wormopolis]

is the idea similar to a post critique? where they have a list of defined "critiques" to choose from and voting for one increases the vote count on a results display?

[Simie]

May 14, 2013 17:52:01 GMT -8 Wormopolis said:

is the idea similar to a post critique? where they have a list of defined "critiques" to choose from and voting for one increases the vote count on a results display?

This:



But I doubt this is the only situation that this problem affects.

[Wormopolis]

similar to this.. but with images:

www.proboards.com/library/plugins/item/122

[Simie]

May 14, 2013 18:34:41 GMT -8 Wormopolis said:

similar to this.. but with images:

www.proboards.com/library/plugins/item/122

Hadn't seen that before, but yes, pretty similar.


Weird, that page said it uses a super key



but it should only use a post key?

[Peter]

May 14, 2013 16:56:01 GMT -8 Simie said:

May 14, 2013 16:51:25 GMT -8 Peter said:

Unfortunately no, as we aren't allowed to perform additional AJAX requests to update the key data before setting it.

Each "set" request overrides the key data, so it becomes an issue when a key is shared amongst staff and members (i.e like my Rate Threads plugin). Obviously on a forum that isn't too active, it probably won't be an issue.

That's what I feared. The additional server load of a fetch before set shouldn't be that great, as it's still caused by a user action. Do you think folks at the top would be open to implementing something like this?

I would agree, though imagine your plugin being super popular and used by 1000's of forums, so I can see why they put a rule in place.

May 15, 2013 0:37:07 GMT -8 Simie said:

May 14, 2013 18:34:41 GMT -8 Wormopolis said:

similar to this.. but with images:

www.proboards.com/library/plugins/item/122

Hadn't seen that before, but yes, pretty similar.


Weird, that page said it uses a super key



but it should only use a post key?

I think this is a bug, am sure I have seen Wormopolis talk about that in the Plugin Library topic with Tim Camara.

[Tim Camara]

Yeah, sorry about that, I should be fixing that today.

[Chris]

May 14, 2013 15:20:36 GMT -8 Simie said:

I'm working on a plugin which uses post keys to provide per-post ratings.

Scenario: 
- User A loads page, reads thread, triggers action which increments post key.
- User B loaded the page before the first user updated the key, triggers an action which increments post key

Result:
User A's increment is not counted.

Is there a way of retrieving the latest value of a key before setting the new value?

Tagging some folks who might know Peter Chris Xikeon Chris Wormopolis Todge

I have yet to encounter this problem but a possible solution comes to mind.
This is just a theory for now and implementation may reveal flaws but perhaps a semaphore-like system employed by your plugin could alleviate this problem somewhat. This of course assumes you're using the recommended JSON format for setting and retrieving keys. I have no knowledge of how your particular plugin chooses to rate and save that data so I'll also assume it is some some kind of aggregate of all the ratings that ultimately gets shown to the end users in order to keep key storage space below the proboards.data('plugin_max_key_length') limit although this could also work if keeping a separate record of each rate/review just with an added layer of complexity.

So your key for post #123 currently looks like this{
"rate" : "23",
"raters" : "7"
}
yielding an average of 3.286 so far.

Now user eton submits a rate of 3 for post #123 so instead of immediately updating rate and raters your plugin adds delayed data{
"rate" : "23",
"raters" : "7",
"eton_TIMESTAMP":"3"
}
On the next page load when the key data which is statically embedded into the page source is updated you can show an aggregate which would include the delayed data including data added by separate processes between the time the last page was loaded and the current page load{
"rate" : "23",
"raters" : "7",
"eton_TIMESTAMP":"3",
"peter3_TIMESTAMP":"2",
"todge_TIMESTAMP":"3"
} yielding a new aggregate of 31/10 = 3.1 which you show to your end users and can finally cleanup when Wormo decides to add a rate to post #123 as well {
"rate" : "28",
"raters" : "9",
"todge_TIMESTAMP":"3",
"tbserialkillers_TIMESTAMP":"5"
} Notice that the timestamps were used to chronologically identify the oldest data and include them in the totals first and that the newest (todge) was left to provide a buffer and on active forums and that buffer could be increased. Another process in another browser would reach (i.e. "write") the same exact totals provided the buffer is sufficient to cover forum activity levels.

[Simie]

May 15, 2013 9:13:02 GMT -8 Chris said:

May 14, 2013 15:20:36 GMT -8 Simie said:

I'm working on a plugin which uses post keys to provide per-post ratings.

Scenario: 
- User A loads page, reads thread, triggers action which increments post key.
- User B loaded the page before the first user updated the key, triggers an action which increments post key

Result:
User A's increment is not counted.

Is there a way of retrieving the latest value of a key before setting the new value?

Tagging some folks who might know Peter Chris Xikeon Chris Wormopolis Todge

I have yet to encounter this problem but a possible solution comes to mind.
This is just a theory for now and implementation may reveal flaws but perhaps a semaphore-like system employed by your plugin could alleviate this problem somewhat. This of course assumes you're using the recommended JSON format for setting and retrieving keys. I have no knowledge of how your particular plugin chooses to rate and save that data so I'll also assume it is some some kind of aggregate of all the ratings that ultimately gets shown to the end users in order to keep key storage space below the proboards.data('plugin_max_key_length') limit although this could also work if keeping a separate record of each rate/review just with an added layer of complexity.

-code-

Hi Eton

I might be misreading your post, but I don't see how this would help if writing a key always overwrites what was already stored.

I'm storing an array of user id's for each rating for now, but this would be a problem with just a simple counter.

Example:

A simple "like" plugin.

- User A loads page, post has 4 'likes' already.
- User B loads page, post has 4 'likes' already.
- User A 'likes' the post. 4+1, User A sets the 'like' counter to 5.
- User B then 'likes' the post some time after User A. As far as User B knows without refreshing, there are only 4 likes. 4+1, User B sets the 'like' counter to 5.
 
To alleviate this problem I'm going to put in a timeout of around a minute after which clicking a rating will cause the page to reload and jump to the post the user attempted to rate. I'd like to automatically set the key upon reload, but that probably violates some rule or other, so I'll probably just put in a message to try voting again.

It would be helpful if an admin could comment on whether setting a key on page load in circumstances like this would be acceptable?

[Wormopolis]

setting a key on a page load is against the rules. Patrick made a sticky about it.

[Simie]

May 15, 2013 10:42:33 GMT -8 Wormopolis said:

setting a key on a page load is against the rules. Patrick made a sticky about it.

I'm considering the spirit of the rule. It's to prevent a key-set on every single page load to reduce load on the servers. This would only key-set on a specific user-initiated page load.

Patrick's example plugin:

Nov 16, 2012 15:58:23 GMT -8 VS Admin said:

Example of acceptable plugin:
You want to create a plugin to track how many people +1 a topic. You create a thread key, and have a button users can click to +1 the topic. When the user clicks the button, you call the plugin key's set() function which triggers the AJAX call.

is affected by the exactly same problem that I'm talking about in this thread.

[Chris]

May 15, 2013 10:31:36 GMT -8 Simie said:

Example:

A simple "like" plugin.

- User A loads page, post has 4 'likes' already.
- User B loads page, post has 4 'likes' already.
- User A 'likes' the post. 4+1, User A sets the 'like' counter to 5.
- User B then 'likes' the post some time after User A. As far as User B knows without refreshing, there are only 4 likes. 4+1, User B sets the 'like' counter to 5.
 

You've missed the core of the method I described which is to delay touching "counter" at all until there are enough pending counter increments to safely determine that "this many increments occurred within this time period and that will not change even if newer increments occur since they are beyond the bounds of the chosen time period". when that period is determined then counter can safely be updated and in the mean time the pendings can be added to counter (but not saved) for display purposes to the user. So in the scenario you give

- User A loads page, post has 4 'likes' already.
- User B loads page, post has 4 'likes' already.
- User A 'likes' the post. 4+1, User A sets the queue to 1 more like (without touching counter).
- User B then 'likes' the post some time after User A. As far as User B knows without refreshing, there are only 4 likes. 4+1, User B sets the queue to 1 more like (without touching counter)
- User A, B or C loads page, post has 4 'likes' plus 2 pending so user is shown "6"
- User C 'likes' post. 6+1, User C sets the queue to 1 more like

Some pendings are finally added to counter on User C's AJAX payload since they have occurred in the "past" and are now reliably certain that they were the only ones that occurred within an arbitrarily defined time period. When user A and User B reloads page they will now see 7 instead of the 5 they expected. In the mean time the counter remains safely locked and protected (like a semaphore system) and updated only when all variables become known.

[Simie]

May 15, 2013 11:17:17 GMT -8 Chris said:

May 15, 2013 10:31:36 GMT -8 Simie said:

Example:

A simple "like" plugin.

- User A loads page, post has 4 'likes' already.
- User B loads page, post has 4 'likes' already.
- User A 'likes' the post. 4+1, User A sets the 'like' counter to 5.
- User B then 'likes' the post some time after User A. As far as User B knows without refreshing, there are only 4 likes. 4+1, User B sets the 'like' counter to 5.
 

You've missed the core of the method I described which is to delay touching "counter" at all until there are enough pending counter increments to safely determine that "this many increments occurred within this time period and that will not change even if newer increments occur since they are beyond the bounds of the chosen time period". when that period is determined then counter can safely be updated and in the mean time the pendings can be added to counter (but not saved) for display purposes to the user. So in the scenario you give

- User A loads page, post has 4 'likes' already.
- User B loads page, post has 4 'likes' already.
- User A 'likes' the post. 4+1, User A sets the queue to 1 more like (without touching counter).
- User B then 'likes' the post some time after User A. As far as User B knows without refreshing, there are only 4 likes. 4+1, User B sets the queue to 1 more like (without touching counter)
- User A, B or C loads page, post has 4 'likes' plus 2 pending so user is shown "6"
- User C 'likes' post. 6+1, User C sets the queue to 1 more like

Some pendings are finally added to counter on User C's AJAX payload since they have occurred in the "past" and are now reliably certain that they were the only ones that occurred within an arbitrarily defined time period. When user A and User B reloads page they will now see 7 instead of the 5 they expected. In the mean time the counter remains safely locked and protected (like a semaphore system) and updated only when all variables become known.

How do you propose storing the queue? Setting the queue to +1 'like' will overwrite any other users who have queued a 'like'.