Async Key Operations

[Chris]

Chris, even I'm a tad confused with your solution.

I don't see how this prevents overriding previous data. PB has no version system. Nothing prevents us from accidentally overriding newer writes.... unless you're somehow suggesting using more than one key.

Simie's scenario is better described as this:
1) User A loads Data v1
2) User B loads Data v1
3) User B writes Data v2
4) User A writes Data v2 as well, since he doesn't know that User B wrote Data v2, because PB has no dynamic loading, thus B's write of v2 is lost.

Issue: We want him to write Data v3 (and use B's v2)

This is a standard issue if there's no semaphore or lock, and there can't be since keys are not pulled from the server on request. They're loaded on page load, thus write conflicts can happen. We have no way to "lock" a variable that can prevent erasing previous writes.

Edit: And as I just said with Simie, we need a PB backend semaphore.

[5/15/13 3:29:01 PM] Chris Dessonville: We need a PB backend semaphore.
[5/15/13 3:29:37 PM] Chris Dessonville: pb.request_and_write_lock("key", function(callback, current_val){  /* something to edit current var */  callback(new_val); }

That'd solve this and be awesome.

[VS Admin]

May 15, 2013 10:49:53 GMT -8 Simie said:

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.

If you want to set a key on page load we ask that you get approval from me first. PM me specific details as to why you need to set a key on page load and I'll let you know if it's acceptable.

[Tim Camara]

I added plugin semaphores into our list of possible features to talk about, so if you ask Pat nicely enough, maybe he'll let us code it.

[Chris]

May 15, 2013 11:21:50 GMT -8 Simie said:

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

The aforementioned "flaw"

May 15, 2013 11:27:04 GMT -8 Chris said:

Chris, even I'm a tad confused with your solution.

I don't see how this prevents overriding previous data. PB has no version system. Nothing prevents us from accidentally overriding newer writes.... unless you're somehow suggesting using more than one key.

I actually wasn't suggesting that I simply failed to take into account that the original problem still existed on queue writes.

May 15, 2013 11:27:04 GMT -8 Chris said:

Simie's scenario is better described as this:
1) User A loads Data v1
2) User B loads Data v1
3) User B writes Data v2
4) User A writes Data v2 as well, since he doesn't know that User B wrote Data v2, because PB has no dynamic loading, thus B's write of v2 is lost.

Issue: We want him to write Data v3 (and use B's v2)

This is a standard issue if there's no semaphore or lock, and there can't be since keys are not pulled from the server on request. They're loaded on page load, thus write conflicts can happen. We have no way to "lock" a variable that can prevent erasing previous writes.

Edit: And as I just said with Simie, we need a PB backend semaphore.

[5/15/13 3:29:01 PM] Chris Dessonville: We need a PB backend semaphore.
[5/15/13 3:29:37 PM] Chris Dessonville: pb.request_and_write_lock("key", function(callback, current_val){  /* something to edit current var */  callback(new_val); }

That'd solve this and be awesome.

It would indeed although I fear implementation would be going against the current trend of reducing resource spending and shrinking the size of code to something you can take and drown in a bathtub.

[Chris]

Chris: Damn. I was hoping I had overlooked something and you had some super awesome solution.

Tim Camara: I can't imagine it being too large of a task to implement stupidly... implementing it in a way to make Martyn happy, now that's a different story. But if you guys could add it, that'd be awesome.

[Simie]

May 15, 2013 12:20:52 GMT -8 Tim Camara said:

I added plugin semaphores into our list of possible features to talk about, so if you ask Pat nicely enough, maybe he'll let us code it.

I'm glad it's on the radar

[Chris]

Did something just change because within that last few minutes I am now getting keys as objects instead of JSON strings that first needed to be parsed?

--

nevermind...