Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(ifcb) admin: changing path on newly-created time series doesn't "take" #68

Closed
joefutrelle opened this issue Sep 18, 2015 · 9 comments
Closed

Comments

@joefutrelle
Copy link
Owner

This is another angular / restless caching issue where changes don't propagate to the database. This only seems to affect newly-created time series--exactly the ones where you would need to change the path. If you reload the admin page or return to it later, path changes "take".

@joefutrelle
Copy link
Owner Author

In both situations (editing path on a new object, editing path on one that existed at load time) the patch that is submitted to the server is correct.

@joefutrelle
Copy link
Owner Author

In the first case the response from the patch is wrong, and contains the old value.

@joefutrelle
Copy link
Owner Author

So the problem is likely on the server side and may have to do with session management. But the patch is handled automagically by restless, and so I'm not sure where to intervene.

@joefutrelle
Copy link
Owner Author

The patch request is wrong in the first case--it looks like there are two competing objects on the client side, and the wrong one is getting changed.

@joefutrelle
Copy link
Owner Author

As expected, if you hit reload when you're looking at a path edit that didn't take, the path will revert to the value that's in the database (the one that didn't get changed by the patch)

@joefutrelle
Copy link
Owner Author

If I add a second path to the newly-created object, it will not be submitted with the patch.

@joefutrelle
Copy link
Owner Author

This looks like it could potentially be related to a bug in restangular:

mgonto/restangular#713

I will try the suggested workaround.

@joefutrelle
Copy link
Owner Author

The suggested workaround worked.

@joefutrelle
Copy link
Owner Author

The workaround should be applied everywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant