-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
HHH-7572 - Develop API for load-by-multiple-ids #1136
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
16 changes: 16 additions & 0 deletions
16
hibernate-core/src/main/java/org/hibernate/loader/BatchLoadSizingStrategy.java
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| /* | ||
| * Hibernate, Relational Persistence for Idiomatic Java | ||
| * | ||
| * License: GNU Lesser General Public License (LGPL), version 2.1 or later. | ||
| * See the lgpl.txt file in the root directory or <http://www.gnu.org/licenses/lgpl-2.1.html>. | ||
| */ | ||
| package org.hibernate.loader; | ||
|
|
||
| /** | ||
| * Strategy (pluggable) for determining an optimal size for batch loads. | ||
| * | ||
| * @author Steve Ebersole | ||
| */ | ||
| public interface BatchLoadSizingStrategy { | ||
| int determineOptimalBatchLoadSize(int numberOfKeyColumns, int numberOfKeys); | ||
| } | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Why is
numberOfKeyColumnspart of the contract? Would be nice to add a JavaDoc comment describing how implementors are meant to utilize it.Also should be the entity type of interest be passed as well? One might want to load small master data table in different chunks than a bug transaction data table for instance.
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, looking further it seems dialect authors are the intended implementors of this contract, not users as I first thought.
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.
Its not part of the JavaDoc because as I stated in the PR description this is intended just for us to discuss. Do you typically fill out JavaDoc for such prototyping?
Well
numberOfKeyColumnsis important to be able to understand how many parameters this translates to in the SQL call for databases that limit the numer of parameters. Loading 1000 entities whose id is made up of 1 column requires 1000 parameters, but loading 1000 entities whose id is made up of 2 column requires 2000 parameters... Big difference.The idea of this is for the Dialect to be able to influence the batch size when we were not told a size by the user as discussed in the Jira.
Look, this is a prototype meant for us to discuss the design. So if you have something you'd like to see different that is the point of this. But really constructive criticism is usually better. So maybe rather than just pointing out what you don't like you could propose an alternative? But in terms of this contract you are just missing the point of it (as it was discussed in the Jira).
As for the user being able to tell us the batch size, the discussion for that (again, on the Jira) was to use
@BatchSize(which is entity specific). Again, if you don't like that then propose a way for that to happen. However I will say that overloading these methods to accept a "batchSize" is not something I would vote for; thats classic implementation details leaking through an API.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.
Yes, I do it where I think it helps reviewers to better understand my draft.
Got it, thanks.
Where did I express any dislike? I asked one question for understanding, followed by a proposal how others could be prevented from asking the same question. I find that very constructive.
Then I made another suggestion (in form of a question). Granted, that suggestion was based on a wrong understanding of the API's purpose - which I acknowledged in my second comment.
I don't see how this can be conceived as not constructive, I am sorry if you got that impression.
Anyways, the contract looks good in this light. Introducing a parameter object may be a good idea with respect to evolution of the API (hint: this is a proposal for an alternative ;).
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.
When the same points are already discussed in the Jira? Ok, bonus points to you I guess...
If we were to go that route, I'd actually just move these from
IdentifierLoadAccessinto a new contract (MultIdentifierLoadAccess?) Ultimately it is the same principle, the difference being that the user isn't having to instantiate that extra object directly.