Hi,
Can someone reproduce this?
1. Click Edit privileges for a user 2. Add a global privilege (let's say SELECT) 3. Click Go 4. Close the popup if needed 5. Click Edit privileges for the same user 6. What I did at step 2 does not reflect in the popup
Hi,
On 8/29/2010 9:40 AM, Marc Delisle wrote:
Hi,
Can someone reproduce this?
- Click Edit privileges for a user
- Add a global privilege (let's say SELECT)
- Click Go
- Close the popup if needed
- Click Edit privileges for the same user
- What I did at step 2 does not reflect in the popup
Confirmed. A quick glance in mysql.user looks like the change was made but isn't refreshed in the popup.
Hi,
Confirmed. A quick glance in mysql.user looks like the change was made
I guess we are facing caching issues like we did with the pagination of the user's list. I remember that Piotr suggested using POST, and I had appended a random number to the GET query at that time. I'll try using POST for all the Ajax queries, otherwise add a random variable to the Ajax queries that require it.
Hi,
I just tried using a POST Ajax request instead of the GET request that currently retrieves the form for editing privileges. It does show the recently changed permissions correctly.
However, POST requests are meant to be used when we would like to submit changes ([0]), while this is a query that just retrieves some HTML. So, if we use POST, we intend to change something in the database, while we don't do that. Hence, is the use of a random number appended to the end of the GET query a more semantically correct method?
-- [0] - http://en.wikipedia.org/wiki/HTTP_POST#Affecting_server_state
Ninad Pundalik a écrit :
Hi,
I just tried using a POST Ajax request instead of the GET request that currently retrieves the form for editing privileges. It does show the recently changed permissions correctly.
However, POST requests are meant to be used when we would like to submit changes ([0]), while this is a query that just retrieves some HTML. So, if we use POST, we intend to change something in the database, while we don't do that. Hence, is the use of a random number appended to the end of the GET query a more semantically correct method?
-- [0] - http://en.wikipedia.org/wiki/HTTP_POST#Affecting_server_state
I would say that the random number would be a better approach; however is this caching issue a jQuery issue that can be notified to the jQuery team? Can we control caching behavior?
On 31/08/2010, Marc Delisle marc@infomarc.info wrote:
I would say that the random number would be a better approach; however is this caching issue a jQuery issue that can be notified to the jQuery team? Can we control caching behavior?
I doubt it will be a jQuery issue. It just makes Ajax requests. The web server's settings would decide what will be served from the cache and what will be processed as a new query.
jQuery let's us set default options for all Ajax requests, so I just added the random number parameter as a default for all actions on the Server Privileges page, and it works. I'll go through all the pages and add this wherever there may be caching issues.
Hi Marc,
Please check commit b947718 in my branch. Added the random number of the Server Privileges, Database Search, Table Search and SQL pages. Have I missed any pages where it could be necessary?
Ninad Pundalik a écrit :
Hi Marc,
Please check commit b947718 in my branch. Added the random number of the Server Privileges, Database Search, Table Search and SQL pages. Have I missed any pages where it could be necessary?
Don't know if it's related but in your repo, adding a column to a table and clicking Save displays "Loading" but it stays on the same page.
On 31/08/2010, Marc Delisle marc@infomarc.info wrote:
Don't know if it's related but in your repo, adding a column to a table and clicking Save displays "Loading" but it stays on the same page.
Due to some mistake, the form on tbl_addfield.php has the same name as the form for creating a new table (used on db_structure.php and db_operations.php). Hence, the Ajax request is being executed correctly, but the response is not in JSON, and hence, the 'Loading' message lingers around even after the request completes successfully. I'll work on Ajaxifying this page tomorrow or the day after.
Ninad Pundalik a écrit :
On 31/08/2010, Marc Delisle marc@infomarc.info wrote:
Don't know if it's related but in your repo, adding a column to a table and clicking Save displays "Loading" but it stays on the same page.
Due to some mistake, the form on tbl_addfield.php has the same name as the form for creating a new table (used on db_structure.php and db_operations.php). Hence, the Ajax request is being executed correctly, but the response is not in JSON, and hence, the 'Loading' message lingers around even after the request completes successfully. I'll work on Ajaxifying this page tomorrow or the day after.
OK. See also this bug report: https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3056649...
On 31/08/2010, Marc Delisle marc@infomarc.info wrote:
OK. See also this bug report: https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3056649...
Fixed in commit 1ea23a2. Two ajax actions had been attached to the change password form on different pages, and this was causing the bug.
Ninad Pundalik a écrit :
On 31/08/2010, Marc Delisle marc@infomarc.info wrote:
OK. See also this bug report: https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3056649...
Fixed in commit 1ea23a2. Two ajax actions had been attached to the change password form on different pages, and this was causing the bug.
Pushed to master, thanks.
On 31 August 2010 23:13, Ninad Pundalik ninadsp16289@gmail.com wrote:
On 31/08/2010, Marc Delisle marc@infomarc.info wrote:
Don't know if it's related but in your repo, adding a column to a table and clicking Save displays "Loading" but it stays on the same page.
Due to some mistake, the form on tbl_addfield.php has the same name as the form for creating a new table (used on db_structure.php and db_operations.php). Hence, the Ajax request is being executed correctly, but the response is not in JSON, and hence, the 'Loading' message lingers around even after the request completes successfully. I'll work on Ajaxifying this page tomorrow or the day after.
Please check commit 285a1b1 on my branch. Sorry that it took a little longer to fix. A couple of things came up and I had no time to look at it last week.
Ninad S. Pundalik
Ninad Pundalik a écrit :
On 31 August 2010 23:13, Ninad Pundalik ninadsp16289@gmail.com wrote:
On 31/08/2010, Marc Delisle marc@infomarc.info wrote:
Don't know if it's related but in your repo, adding a column to a table and clicking Save displays "Loading" but it stays on the same page.
Due to some mistake, the form on tbl_addfield.php has the same name as the form for creating a new table (used on db_structure.php and db_operations.php). Hence, the Ajax request is being executed correctly, but the response is not in JSON, and hence, the 'Loading' message lingers around even after the request completes successfully. I'll work on Ajaxifying this page tomorrow or the day after.
Please check commit 285a1b1 on my branch. Sorry that it took a little longer to fix. A couple of things came up and I had no time to look at it last week.
Hi Ninad, in your tree, adding a column now shows correctly "table xxx has been altered successfully" but stays on the same page.
Applying 285a1b1 to current master does not show this message, and it stays on the same page. Any other commit to apply with this one?
Ninad Pundalik a écrit :
Hi Marc,
Please check commit b947718 in my branch. Added the random number of the Server Privileges, Database Search, Table Search and SQL pages. Have I missed any pages where it could be necessary?
Commit b947718 merged to master.
2010/8/31 Marc Delisle marc@infomarc.info:
Ninad Pundalik a écrit :
Hi Marc,
Please check commit b947718 in my branch. Added the random number of the Server Privileges, Database Search, Table Search and SQL pages. Have I missed any pages where it could be necessary?
Commit b947718 merged to master.
Random numbers can result in eq. 1 per million request to show stale data (due to browser or proxy cache'ing). I believe using POST is a better solution, as it covers even these (unlikely, but still existing) edge cases.
Have you tried to issue cache'ing headers on the server to prevent cache'ing? That would solve this problem - you use GET with no workarounds.
Hi Piotr,
On 01/09/2010, Piotr Przybylski piotr.prz@gmail.com wrote:
Random numbers can result in eq. 1 per million request to show stale data (due to browser or proxy cache'ing). I believe using POST is a better solution, as it covers even these (unlikely, but still existing) edge cases.
Have you tried to issue cache'ing headers on the server to prevent cache'ing? That would solve this problem - you use GET with no workarounds.
I checked the online documentation of jQuery (I have a slightly older version, 1.3), and found an option that prevent cached requests from being served. I tried using it today, but was not able to get any results. I'll go through the docs again, and give it another shot tomorrow.
Thanks! :)
2010/9/1 Ninad Pundalik ninadsp16289@gmail.com:
Hi Piotr,
On 01/09/2010, Piotr Przybylski piotr.prz@gmail.com wrote:
Random numbers can result in eq. 1 per million request to show stale data (due to browser or proxy cache'ing). I believe using POST is a better solution, as it covers even these (unlikely, but still existing) edge cases.
Have you tried to issue cache'ing headers on the server to prevent cache'ing? That would solve this problem - you use GET with no workarounds.
I checked the online documentation of jQuery (I have a slightly older version, 1.3), and found an option that prevent cached requests from being served. I tried using it today, but was not able to get any results. I'll go through the docs again, and give it another shot tomorrow.
Thanks! :)
If it fails, along with JSON reply send HTTP headers to prevent browser cache'ing (Cache-Control / Expires).
Hi,
On 02/09/2010, Piotr Przybylski piotr.prz@gmail.com wrote:
If it fails, along with JSON reply send HTTP headers to prevent browser cache'ing (Cache-Control / Expires).
Added the necessary HTTP headers as well as added the cache setting for Ajax requests in jQuery. My testing seems to show that both work. Do check commit 8206298 on my branch.
Thanks!
Ninad Pundalik a écrit :
Hi,
On 02/09/2010, Piotr Przybylski piotr.prz@gmail.com wrote:
If it fails, along with JSON reply send HTTP headers to prevent browser cache'ing (Cache-Control / Expires).
Added the necessary HTTP headers as well as added the cache setting for Ajax requests in jQuery. My testing seems to show that both work. Do check commit 8206298 on my branch.
Thanks!
Seems to run fine in my (limited) tests. Pushed to master.
-
Isaac Bennetch -
Marc Delisle -
Ninad Pundalik -
Piotr Przybylski