You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, virtual properties can be anything. For example, a virtual property could be "is_recent" that compares the creation time of an entity against now() and returns true if created in the last hour or false otherwise.
The problem here is that apparent data on the objects can change value but not change the 'state' of the class of objects.
Say our current state is 0, and we call setFoos/create. Our state becomes 1, and our object has a is_recent of true.
In 2 hours, is_recent is now false, but state is still 0. Now our client and server are out of sync, and if the client says getFooUpdates sinceState => 1, the server will say nothing has changed.
Is this something we can defend against consumers mistakenly doing, or should we minimize these types of issues through the documentation?
The text was updated successfully, but these errors were encountered:
Right now, virtual properties can be anything. For example, a virtual property could be "is_recent" that compares the creation time of an entity against now() and returns true if created in the last hour or false otherwise.
The problem here is that apparent data on the objects can change value but not change the 'state' of the class of objects.
Say our current state is 0, and we call setFoos/create. Our state becomes 1, and our object has a is_recent of true.
In 2 hours, is_recent is now false, but state is still 0. Now our client and server are out of sync, and if the client says getFooUpdates sinceState => 1, the server will say nothing has changed.
Is this something we can defend against consumers mistakenly doing, or should we minimize these types of issues through the documentation?
The text was updated successfully, but these errors were encountered: