-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: do not use QuerySpec
when SqlContractDefinitionStore#findAll()
#1539
Fix: do not use QuerySpec
when SqlContractDefinitionStore#findAll()
#1539
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1539 +/- ##
==========================================
- Coverage 67.16% 67.12% -0.04%
==========================================
Files 736 736
Lines 16139 16144 +5
Branches 1048 1050 +2
==========================================
- Hits 10839 10836 -3
- Misses 4823 4831 +8
Partials 477 477
Continue to review full report at Codecov.
|
fd422b6
to
bd98be1
Compare
@@ -69,7 +69,15 @@ ContractDefinition mapResultSet(ResultSet resultSet) throws Exception { | |||
|
|||
@Override | |||
public @NotNull Collection<ContractDefinition> findAll() { | |||
return findAll(QuerySpec.none()).collect(Collectors.toList()); | |||
return transactionContext.execute(() -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would make this more explicit as it was done in the SqlAssetIndex
at line 132, passing to the other findAll
method a QuerySpec
instance with an insanely high limit
value.
In this way the thing will be explicit (as I would expect this to change in the future), there will be no duplication and no SQL syntax will overflow in the store implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There isn't really any duplication, there is just two (slightly) different SQL statements. In reality those two approaches would have the same effect, and once we have true pagination in IDS, we can remove the parameterless findAll()
method completely. So I'd either leave it as is, because after all, it's a "true" findAll or remove the findAll
altogether :)
What do you mean by "SQL syntax overflow"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
having a string with SELECT something FROM somewhere
in the Store
/Index
, we never did that anywhere else, all the SQL stuff is in the Statements
class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah got it what you mean. How about we remove findAll()
altogether then, and provide a static method QuerySpec.max()
that creates a QuerySpec with limit = Integer.MAX_VALUE
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this commit removes the parameterless findAll()
. WDYT?
ec62ff0
to
a73fa53
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally agree on findAll()
's inline. Good for me then
What this PR changes/adds
Does not use a
QuerySpec
when executingSqlContractDefinitionStore#findAll
, instead execute a plainSELECT * FROM...
.Why it does that
all = no limits!
Linked Issue(s)
Closes #1515
Checklist
no-changelog
)