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

Batch remove entries #5659

Merged
merged 44 commits into from
Nov 26, 2019
Merged

Batch remove entries #5659

merged 44 commits into from
Nov 26, 2019

Conversation

abepolk
Copy link
Contributor

@abepolk abepolk commented Nov 22, 2019

I changed the SQL in DBMSProcessor so that multiple entries are deleted with one query instead of using a query for each entry. This was the original rationale for the refactoring I did in October.


Copy link
Member

@koppor koppor left a comment

Choose a reason for hiding this comment

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

LGTM. Thank you for following-up.

@@ -164,18 +164,46 @@ void testUpdateEqualEntry(DBMSType dbmsType, DBMSConnection dbmsConnection, DBMS

@ParameterizedTest
@MethodSource("org.jabref.logic.shared.TestManager#getTestingDatabaseSystems")
void testRemoveEntry(DBMSType dbmsType, DBMSConnection dbmsConnection, DBMSProcessor dbmsProcessor) throws SQLException {
Copy link
Member

Choose a reason for hiding this comment

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

Can be keep the single test? -> Meaning the additional test for two entries is OK, but we should also keep the simple (and probably always succeeding test). - Reason: The for loop above is not entered for one entry and thus this test case is special.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could, but it would still have to be dbmsProcessor.removeEntries(Collections.singletonList(entryToRemove)) because I got rid of DBMSProcessor.removeEntry in the singular. Is it still worth it?

Copy link
Member

Choose a reason for hiding this comment

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

Sure. The tests should be independent of the implemention somehow. Tests should cover the general case, but also edge cases, null list, 0 element list, list with 1 elements, list with integer.max elements (which is impossible IMHO), but the other cases should be easy to do?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, in that case I will use Collections.singletonList. Should I add a test for each of those edge cases as well?

Copy link
Member

Choose a reason for hiding this comment

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

Sure, please go ahead. In case tests are easy to write, they should be written. - The thing is: The implementation could change in 1 year (who knows) and the test will still cover that case.

Please also add a test for

  • dbmsProcessor.removeEntries(Collections.emptyList())
  • dbmsProcessor.removeEntries(null) (should throw a NPE)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Throw on empty list? If so, throw what? I can't imagine why someone would want to call removeEntries on purpose on an empty list.

@koppor
Copy link
Member

koppor commented Nov 22, 2019

Minor thing: checkstyle should be fixed 😇

Copy link
Member

@tobiasdiez tobiasdiez left a comment

Choose a reason for hiding this comment

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

Just a minor suggestion, otherwise looks very good to me! Thanks

.append(" = ?");
.append(" IN (");
for (int i = 0; i < bibEntries.size() - 1; i++) {
query.append("?, ");
Copy link
Member

Choose a reason for hiding this comment

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

I think you can use "?, ".repeat(bibEntries.size())` here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Made the change, will push soon.

@koppor koppor merged commit 917defc into JabRef:master Nov 26, 2019
@koppor
Copy link
Member

koppor commented Nov 26, 2019

I merged to move ahead. Think, the software engineering discussion can be done later :)

Because the unit tests are not only for the current version of the code. They are especially for all future versions and if somebody changes the code and does not know what s/he did, the test can fail and tell him that he did something wrong. So you can't say that this will never happen.

https://sqa.stackexchange.com/a/9009/28592

Thus, I argue for improper usage - who knows, what future code will bring.

@abepolk
Copy link
Contributor Author

abepolk commented Dec 1, 2019

Thanks! Is there any way I can fix this in my following PR?

@abepolk abepolk mentioned this pull request Dec 2, 2019
5 tasks
@koppor koppor mentioned this pull request Dec 4, 2019
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