-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Table: Entity getters assume strings, but there is no check #123
Milestone
Comments
fix would be breaking change, close. |
gcheng
pushed a commit
that referenced
this issue
Jun 25, 2013
jianghaolu
pushed a commit
to jianghaolu/azure-sdk-for-java
that referenced
this issue
Apr 5, 2017
sima-zhu
pushed a commit
to sima-zhu/azure-sdk-for-java
that referenced
this issue
Mar 21, 2019
Return null on GET 404
mssfang
pushed a commit
to mssfang/azure-sdk-for-java
that referenced
this issue
Apr 23, 2019
Adding two tests, as regression tests for two recently fixed issues. 1. Accept Session timeout on the client shouldn't cause the session to be locked on the service. 2. RequestResponse link shouldn't allow just 5000 requests to the backend.
navalev
pushed a commit
to navalev/azure-sdk-for-java
that referenced
this issue
Dec 24, 2019
api version is optional. …
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Moved from private repository
One can use the Entity.setPRoperty method to set PartitionKey and RowKey properties to non-string values, but when trying to read them back via getRowKey or getPartitionKey, those methods will throw with something like "java.lang.ClassCastException: java.lang.Double cannot be cast to java.lang.String".
One approach would by to try to redesign the getters, but that seems wrong. The base problem is that those properties are special (must be set before submission, must be strings, must have EdmType null or "STRING", etc.)
The better approach would be to add validation when setting the properties with setProperty (check for the special properties) and setProperties (look through the map for the special properties). There is still a hole where one could directly add a property to the Map, but there is not much we can do there and it is more likely that people will add properties through the entity directly.
Regardless, there will still need to be pre-submission validation as well.
Here are the troublesome property getters, where no validation is done before getting the value:
The text was updated successfully, but these errors were encountered: