Can javascript read a row from embedded cloudtable in 1 transaction so the row data isn't changing?
Can javascript read a row from embedded cloudtable in 1 transaction so the row data isn't changing?
pmarks906d
Posts: 61Questions: 18Answers: 0
I have embedded a cloudtable on a page. My javascript currently successfully reads from this table and uses the data to fill out my page. I believe that when I add, delete or update a cloudtable row somewhere else on the web (using the cloudtable editor) the row data is automatically pushed to the cloudtable embedded on my page. Is there a way for my javascript to atomically read a row from that embedded table such that the row data is (hopefully guaranteed to be all there at once and) not changing in the middle of the read? If so what would the syntax look like? Thanks.
This question has an accepted answers - jump to answer
Answers
I'm not entirely sure what you mean I'm afraid. The write performed is atomic, so at the point of reading the data is complete and in-sync. The read action performed on the client-side is synchronous, so the data can't change during the read. It might change either side of if, but that is an async act caused by someone else updated data else where.
Allan
Thanks for your quick response. Please bear with me I'm just trying to get this straight.
* I think it is true that when a row is submitted by an editor somewhere else on the web, on the client side my javascript cannot tell exactly when a row-update into my embedded table will occur or has occurred.
* However, if i poll the embedded table periodically on my client side, eventually i will get the last row data submitted by an editor.
* Are you saying that since the javascript is synchronous with respect to the embedded table updates, that when my periodic read function wakes up, it can use a bunch of cell(x,y) calls to iterate over and read data from a row of my embedded table and the row data won't change between cell() calls?
* Thus the row data this function reads before it goes back to sleep is always exactly what was entered in the an editor when the row was submitted somewhere else on the web.
* The row data could change before my function wakes up, and after it completes, but not during my periodic function.
* Secondly, is it also true that while my periodic function is running, the embedded table is guaranteed not be updated at all until the function ends?
Is this correct? Thanks
The main thing I'm trying to do is to poll my embedded table to determine if something has changed so I'll know when to refresh parts or all of my page. Basically, a row could be deleted, a row could be added, and a row data could be changed.
Since the changes to a cloudtable, made by an editor somewhere else on the web, are automatically pushed to all embedded tables even while their webpages are open, I'm trying to use that feature to update my pages as the changes occur, without having to reload my pages to get the latest cloudtable updates.
I'm with you - unfortunately there is no external API for that push event yet. It is something that I hope to add in future, but at the moment, there is no way to hook into it - either directly against CloudTables' web-socket, or with DataTables' API.
At this time, a poll is the only real option. Sorry.
Allan
Polling is fine. I just need to know if when I poll that the data doesn't update in the middle of the function which is reading from the embedded table. Is the embedded table guaranteed not to update in the middle of the function which is reading from it? If the table doesn't update in the middle of the function which is reading from it I can accomplish all I need to by polling. thanks
Your request for data via the API is handled by a single database transaction. So yes, it is guaranteed to not change while it was being read. How many updates per second are you expecting? CloudTables is optimised for read, rather than write operations. Also, even if one row were to change, it can't affect the others, so I'm not sure I see why it would be a problem even if one row did update while the data was being read? Finally, how large is your data set? While the API doesn't implement paging yet, it might need to in future as data sets grow in size.
Allan