Skip to content
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

621: Generic Read Metadata #1019

Merged
merged 26 commits into from
Apr 16, 2024
Merged

621: Generic Read Metadata #1019

merged 26 commits into from
Apr 16, 2024

Conversation

halprin
Copy link
Member

@halprin halprin commented Apr 12, 2024

Generic Read Metadata

Made reading from the database generic. It used to be highly coupled to the metadata concept. It can now support arbitrary SQL statements and conversions.

Issue

#621.

Checklist

  • I have added tests to cover my changes
  • I have added logging where useful (with appropriate log level)
  • I have added JavaDocs where required
  • I have updated the documentation accordingly

Note: You may remove items that are not applicable

@halprin halprin marked this pull request as ready for review April 15, 2024 23:13
Copy link
Contributor

@basiliskus basiliskus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! I just noticed some test coverage is missing for the exception path in fetchManyData

try {
PreparedStatement statement =
connection.prepareStatement(
"SELECT * FROM metadata where received_message_id = ? OR sent_message_id = ?");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At some point I think we should separate SQL code from Java code. In the meantime I've been placing the sql code in a variable at the start of the method where it's used, but we should probably start putting them in a more centralized place soon. It could be external files or java constants

connection -> {
try {
PreparedStatement statement =
connection.prepareStatement(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is nice. For some time I've been thinking of having a wrapper class that will handle the prepared statements. Thoughts on having the wrapper class so that both storage classes can use it with the dao?

* ResultSetIterator iterates over a SQL {@link ResultSet}. This helps stream over a {@link
* ResultSet}.
*/
public class ResultSetIterator implements Iterator<ResultSet> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on implementing the AutoCloseable interface to manage the closure of ResultSet in case the iterator is not fully traversed until the end?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is handled outside of the iterator in PostgresDao#fetchData and PostgresDao#fetchManyData already. We put the ResultSet inside the try-with-resources immediately as we get the ResultSet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see it.

Copy link
Contributor

@jorg3lopez jorg3lopez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job, looks good.

@jorg3lopez
Copy link
Contributor

Nice work, the only thing I see that might need attention is the test coverage. Other than that, everything looks good.

@@ -14,18 +14,14 @@ class JjwtEngineTest extends Specification {

def "readPrivateKey works"() {
given:
def expected = """SunRsaSign RSA private CRT key, 2048 bits
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason this test started to fail in GitHub for me. I decided to refactor the test to not depend on toString().

Copy link
Contributor

@basiliskus basiliskus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

Copy link

sonarcloud bot commented Apr 16, 2024

@halprin halprin merged commit 49dae5b into main Apr 16, 2024
15 checks passed
@halprin halprin deleted the story-621-read_metadata_generic branch April 16, 2024 22:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants