Repository navigation
'select' with invalid attribute names fails silently #3
Description
Example:
select with valid attributes:
>>> v1.Scope.filter("Name='My Project'").select('Name', 'AssetType').first()
Scope(71376).with_data({'AssetType': 'Scope', 'Name': 'My Project'})
select with an invalid attribute name (eg: Number)
>>> v1.Scope.filter("Name='My Project'").select('Name', 'AssetType', 'Number').first()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/campbr9/.virtualenvs/v1cli/lib/python2.6/site-packages/v1pysdk-0.2-py2.6.egg/v1pysdk/query.py", line 92, in first
return list(self)[0]
IndexError: list index out of range
This is a bit deceptive, because there is no way of telling if you supplied the select wrong, or there actually wasn't anything that matched the query.
Interestingly enough, an error is reported by the API, it just isn't propagated to the user:
GET: http://versionone.example.com/VersionOne/rest-1.v1/Data/Scope/71376?sel=Name,Number
<Error href="/VersionOne/rest-1.v1/Data/Scope/71376?sel=Name,Number">
<Message>Invalid SEL parameter</Message>
<Exception class="VersionOne.MetaException">
<Message>Unknown token: Number</Message>
</Exception>
<Exception class="VersionOne.MultipleException">
<Message>
(1) Unknown AttributeDefinition: Scope.Number (2) Unknown token: Number
</Message>
</Exception>
</Error>
Thanks,
Ryan
Activity
jkoberg commentedon Nov 30, 2012
On my instance, that query returns a HTTP 400 error code, which raises a v1pysdk.V1Error on line 90 of client.py . Can you use Chrome's debugging pane (F12) to see if you're getting the 400 error code on the network request?
campbellr commentedon Nov 30, 2012
Interesting. My server is definitely returning a 400 too, according to Chrome at least.
I'll try to do some more digging around to see why v1pysdk isn't raising this in my case.
campbellr commentedon Dec 3, 2012
So far it seems like there might be something wrong with the custom opener, but I haven't figured out what exactly:
So even though I'm getting a 400 status code, the opener isn't raising an HTTPError (it does have HTTPDefaultErrorHandler as the default error handler though)
This could have something to do with the fact that I'm using the HTTPNtlmAuthHandler, since that's likely the only real difference.
ntlm: raise HTTPErrors when appropriate. Fixes issue versionone#3
ntlm: raise HTTPErrors when appropriate. Fixes issue versionone#3
campbellr commentedon Dec 6, 2012
I managed to fix this in my fork. Let me know if you are interested in merging it and I can create a pull request. Ideally something like this would go into python-ntlm, but seeing as a similar issue has been on the bug-tracker since 2008, I don't know if that's going to happen...
jkoberg commentedon May 16, 2013
if you still have the code, please do issue a pull request. I apologize for the long delay.
ntlm: raise HTTPErrors when appropriate. Fixes issue versionone#3
ntlm: raise HTTPErrors when appropriate. Fixes issue #3
jkoberg commentedon Jul 29, 2013
Pulled this commit. thanks.