Rough fixes for a couple of issues I've encountered - #6
Conversation
…ntaining UpdatedDateUTC comparison i.e. UpdatedDateUTC > new DateTime(2010,1,1).
…ies that can only be populated via the API (useful if being used to coordinate synchronization with external systems).
|
Cool. I'll have a look at this early next week. Any changes to ApiQueryTranslator.cs needs a clear head :) Dan.. |
|
Hi Alex, I've just reviewed and committed the changes that you submitted. The NULL comparison in WHERE queries seems straightforward and useful. The second issue around nested binary expressions with ElementId/ElementNumber/ElementUpdatedDate properties is a little more tricky. We're currently working on a change to the XeroAPI service to parse these filters from the WHERE querystring on the server side. For the time being, the code you submitted works fine. Thanks for your input! Dan.. |
|
Thanks Dan, Yeah my work-around for the second issue is obviously a hack i.e. > and >= get treated the same for ElementUpdatedDate when translated for instance, but at least it means when you do address it properly in the future, I shouldn't have to change my code client-side too much. Cheers, Alex |
I've found a couple of issues when using fields in queries that are automatically extracted from the where clause by the ApiQueryTranslator i.e. ElementNumber and ElementUpdatedDate properties, which result in either invalid expressions being generated, or values being incorrectly extracted when testing for null/not-null.
The fixes are pretty naive - If I had more time I would be inclined to write a separate visitor/expression rewriter for extracting the ElementId/ElementNumber/ElementUpdatedDate and rewriting expression to exclude that info / removing member expressions and parent binary expressions as necessary before it is passed onto the current ApiQueryTranslator, as that would keep things a little simpler to read/understand.
That said, Liking the Linq translator otherwise though :) nice and easy