deleteWhere regression in 0.40.1
See original GitHub issueAfter upgrading to 0.40.1 the following code does not compile
TableA.deleteWhere { TableA.id eq myId }
Getting Unresolved reference: eq
Issue Analytics
- State:
- Created a year ago
- Reactions:3
- Comments:10 (7 by maintainers)
Top Results From Across the Web
Issues · JetBrains/Exposed - GitHub
deleteWhere regression in 0.40.1 bug. #1610 opened on Oct 13 by lukas-krecan · 10 · newSuspendedTransaction connecting to old database instances across test ......
Read more >Regression Examples
Automatically back-transforms estimates and confidence intervals, when the model requires it. Can use robust standard errors for the calculation ...
Read more >Statistics review 7: Correlation and regression - PMC - NCBI
The present review introduces methods of analyzing the relationship between two quantitative variables. The calculation and interpretation of the sample ...
Read more >Regression Analysis - SPH - Boston University
Simple linear regression is a technique that is appropriate to understand the association between one independent (or predictor) variable and ...
Read more >Regression with Stata Chapter 1 – Simple and Multiple ...
1.0 Introduction · 1.1 A First Regression Analysis · 1.2 Examining Data · 1.3 Simple linear regression · 1.4 Multiple regression · 1.5...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
It should become better after context receivers go public
Is this the suggested way? Regardless of the
ISqlExpressionBuilder
at theit
parameter?In my understanding, either the
ISqlExpressionBuilder
parameter is useless, or direct imports should not be used.My current workaround:
It’s kotlin’s limitation of now allowing two receivers in lambda blocks. In case of two parameters competing the receiver position, libraries should make trade-offs. The
ISqlExpressionBuilder
as a receiver can be seen as a “context”, although I don’t know the implementation detail, but it can differ according to different senarios such as different SQL dialects etc. While theTable
as a receiver acts only as a syntax sugar.If the
ISqlExpressionBuilder
parameter could not be removed, I believe the old way is much more reasonable, since theTable
is defined by users, users know how to use it.