Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Implementation of custom operations may not be overloaded
See original GitHub issueHey guys, I was looking to join on multiple columns and found issue 36. I actually want a left outer join on multiple columns, not an inner join, but that is besides the point.
When I try to upgrade to a later version than 2.1.0 it breaks all of my existing (working) code, with the following error message:
The custom operation 'orderBy' refers to a method which is overloaded. The implementations of custom operations may not be overloaded.F# Compiler(3087)
It appears the F# compiler does not allow overloads for custom operations, and after version 2.1.0 this seems to be how you have implemented both more orderBy stuff and the aforementioned innerJoin on multiple columns. I really appreciate these new features, but how am I supposed to use it?
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Thank you, no I agree overloading is a great feature and works very well with this api! It was just kind of strange that it needed an obscure flag, and what is worse, trying to google the error message I got (before I knew of the flag) sent me to old F# discussion threads where it was argued that overloading like that would never be supported and wasn’t a good idea. I disagree with that obviously and think overloading here is a good idea and I’m happy seeing it move into 5. But it was a very confusing ride trying to debug what the hell was going on.
I can also see that the Linq syntax might be better, and I would surely have used it if that was the predominant form in the examples / docs, but that wasn’t the case when I first started this project and I’m not keen on rewriting all my queries. Although static guarantees make a good case!
It’s common for new features to be staged as preview only features.
The Linq API has a major advantage over the base API in that it uses strongly typed records to represent tables and record properties to represent columns. This means that it’s impossible to accidentally misspell a table or column in your query, and the mistakes that would be caught at run-time (like entering your join columns in the wrong order) will instead be caught at design-time.
In fact, the base API will likely be removed in favor of the Linq API in v3.0.
Also, there are no overloaded operators in the Linq API, so you won’t need the
previewtag. 🙂