Skip to content

Conversation

robfrank
Copy link
Collaborator

@robfrank robfrank commented Jul 3, 2025

What does this PR do?

A brief description of the change being made with this pull request.

Motivation

What inspired you to submit this pull request?

Related issues

A list of issues either fixed, containing architectural discussions, otherwise relevant
for this Pull Request.

Additional Notes

Anything else we should know when reviewing?

Checklist

  • I have run the build using mvn clean package command
  • My unit tests cover both failure and success scenarios

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Summary of Changes

Hello @robfrank, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new unit test to validate the integrity of results returned when querying non-unique LSM tree indexes. The test ensures that even when multiple documents share the same indexed key, the database correctly retrieves distinct documents, preventing any spurious duplicates in the result set.

Highlights

  • New Unit Test for LSM Index: A new JUnit 5 test file, Issue2328Test.java, has been added to the engine module. This test focuses on verifying the behavior of LSM (Log-Structured Merge-tree) indexes.
  • Distinct Value Retrieval Verification: The notUniqueShouldReturnDistinctValues test method specifically checks that when querying a non-unique LSM index, the result set does not contain duplicate documents. It achieves this by populating the database with documents where the indexed key (p2) is intentionally duplicated across multiple documents, but a different property (p1) remains unique per document. The test then asserts that all p1 values retrieved from the query are distinct.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in issue comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request adds a new unit test to verify that queries on a non-unique LSM index return distinct records. The test logic is sound. I've provided a few suggestions to improve the test code's quality and maintainability by adhering to common testing best practices.

Comment on lines +23 to +24
final File tmp = File.createTempFile("ArcadeTmp", "");
tmp.delete();
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

This method of creating a temporary directory path has a potential race condition and does not guarantee cleanup of the database files after the test runs. It's recommended to use JUnit 5's @TempDir annotation, which provides a temporary directory and handles its cleanup automatically.

System.out.println("Tmp Database: " + tmp);

try(final DatabaseFactory fact = new DatabaseFactory(tmp.toString())){
try(final LocalDatabase local = (LocalDatabase) fact.create()){
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

It's a good practice to program against interfaces rather than concrete implementations. The fact.create() method returns a Database, and all subsequent calls on local are available on the Database interface. Casting to LocalDatabase is unnecessary here and makes the code more flexible.

Suggested change
try(final LocalDatabase local = (LocalDatabase) fact.create()){
try(final Database local = fact.create()){

Comment on lines +84 to +85
System.out.println("Found: " + count);
System.out.println("Duplicates: " + dup);
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

While System.out.println is useful for debugging, it's generally better to avoid it in unit tests as it can clutter the output of test runs. This applies to other println calls in this test as well (lines 25, 72, 80). Consider removing them.

Comment on lines +86 to +88
if(dup>0) {
throw new IllegalStateException("Duplicates found: " + dup);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

It's better to use JUnit assertions in tests instead of throwing an exception. This provides better integration with testing frameworks and build tools, often giving more informative failure reports.

org.junit.jupiter.api.Assertions.assertEquals(0, dup, "Duplicates found: " + dup);

Copy link

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
-0.03%
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (9eb0d2b) 70576 45370 64.29%
Head commit (e809432) 70576 (+0) 45348 (-22) 64.25% (-0.03%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#2330) 0 0 ∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

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.

1 participant