'select' with invalid attribute names fails silently

[campbellr]

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

[jkoberg]

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]

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]

So far it seems like there might be something wrong with the custom opener, but I haven't figured out what exactly:

url = <url with invalid 'sel='>
>>> r = v1.server.opener.open(url)
>>> r.code
400
>>> url = <some invalid url>
>>> r = v1.server.opener.open(url)
>>> r.code
404

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.

[campbellr]

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]

if you still have the code, please do issue a pull request. I apologize for the long delay.

[jkoberg]

Pulled this commit. thanks.