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

Select the entry which has smaller dictonary order when merge #7708

Merged
merged 6 commits into from
May 10, 2021

Conversation

SuXiChangZhen
Copy link
Contributor

Changed the selected entry when merge two entries:
if two entry's citation key are empty, the above one will be selected;
if only one entry has citation key, then it will be selected;
if two entries both have citation key, the one who has smaller dictionary order will be selected.
Fixes #7395

The screenshot shows that the "2021a" is selected although it is below "2021b".
test-for-7395

  • Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
  • Tests created for changes (if applicable)
  • Manually tested changed features in running JabRef (always required)
  • Screenshots added in PR description (for UI changes)
  • Checked documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

@Siedlerchr
Copy link
Member

SEe Checkstyle ore reviewdog and please give your PR a better title

@JabRef JabRef deleted a comment from Siedlerchr May 6, 2021
@JabRef JabRef deleted a comment from Siedlerchr May 6, 2021
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.

Thank you for working on this.

Please do not add business logic the the gui. business logic in our case is the comparision of BibEntries. We have the org.jabref.logic.bibtex.comparator.EntryComparator. I made code suggestions inside.

Comment on lines 55 to 70
// Compare the citation key
BibEntry first = one;
BibEntry second = two;

Optional<String> keyOne = one.getCitationKey();
Optional<String> keyTwo = two.getCitationKey();
if (keyOne.isPresent() && keyTwo.isPresent() && keyOne.get().compareTo(keyTwo.get()) > 0) {
first = two;
second = one;
}
else {
if (keyTwo.isPresent()) {
first = two;
second = one;
}
}
Copy link
Member

Choose a reason for hiding this comment

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

There is org.jabref.logic.bibtex.comparator.EntryComparator:

EntryComparator(false, true, InternalField.KEY_FIELD)

Thus:

Suggested change
// Compare the citation key
BibEntry first = one;
BibEntry second = two;
Optional<String> keyOne = one.getCitationKey();
Optional<String> keyTwo = two.getCitationKey();
if (keyOne.isPresent() && keyTwo.isPresent() && keyOne.get().compareTo(keyTwo.get()) > 0) {
first = two;
second = one;
}
else {
if (keyTwo.isPresent()) {
first = two;
second = one;
}
}
BibEntry first;
BibEntry second;
EntryComparator entryComparator = new EntryComparator(false, true, InternalField.KEY_FIELD);
if (entryComparator.compare(one, two) <= 0) {
first = one;
second = two;
} else {
first = two;
second = one;
}

Since software engineering is an engineering prinicple and engineering includes testing, please add test cases. Add them to the class org.jabref.logic.bibtex.comparator.EntryComparatorTest

@koppor koppor added the status: changes required Pull requests that are not yet complete label May 6, 2021
@SuXiChangZhen SuXiChangZhen changed the title fix issue 7395 Select the entry which has smaller dictonary order when merge May 7, 2021
@SuXiChangZhen
Copy link
Contributor Author

Thank you for your suggestions. I have used EntryComparator and added two test cases to test the behavior of EntryComparator.

@k3KAW8Pnf7mkmdSMPHz27
Copy link
Sponsor Member

k3KAW8Pnf7mkmdSMPHz27 commented May 7, 2021

I like the idea of having a default order when merging, but isn't this a problem when one citation key is empty ("" not null) and the other one is not? Can that happen and is it worth worrying about?

@SuXiChangZhen
Copy link
Contributor Author

Yes, I think the real problem may be how to define a valid citation key. For example, " " should not be a valid one

@Siedlerchr
Copy link
Member

An empty citation key is totally valid. I would expect to have the empty one as "lower" on the left in the dialog
Minimum valid bibtex:

@Article{,
}

@SuXiChangZhen
Copy link
Contributor Author

Yes, that make sense too. It seems some checks were not successful, so what should I do?

@Siedlerchr
Copy link
Member

You should merge in the latest main from upstream jabref, then most tests should be working again.
Checkstyle + Unit tests must be green

@koppor
Copy link
Member

koppor commented May 7, 2021

I like the idea of having a default order when merging, but isn't this a problem when one citation key is empty ("" not null) and the other one is not? Can that happen and is it worth worrying about?

This should be handled by the EntryComparator, too. Test cases should cover this. @SuXiChangZhen Please add this test case to EntryComparatorTest.

@koppor
Copy link
Member

koppor commented May 7, 2021

Yes, I think the real problem may be how to define a valid citation key. For example, " " should not be a valid one

Since .bib is a text file where users can input (nearly) arbitrary things, we have to be relaxed in as many places as possible.

We have the org.jabref.logic.integrity.CitationKeyChecker which checks for the empty key.

@k3KAW8Pnf7mkmdSMPHz27
Copy link
Sponsor Member

k3KAW8Pnf7mkmdSMPHz27 commented May 7, 2021

I am not that up to date with the merging and I might have sown some accidental confusion, sorry 😜

Based on how JabRef generates duplicate keys some cases are "easier" to deal with.

If the generated citation key is 2021 duplicated citation keys will be 2021a, 2021b, etc. and it is indeed correct that 2021a should be preferred over 2021b just as 2021 should be preferred over 2021a (this might be a good test-case as well).

But if you are merging and 2021, , should in my opinion not be sorted above 2021.

As I said, this might very well not be worth worrying about.

@koppor
Copy link
Member

koppor commented May 7, 2021

But if you are merging and 2021, , should in my opinion not be sorted above 2021.

Fair! I did not "see" that case.

Then this is a call for CitationKeyComparator in the package org.jabref.logic.bibtex.comparator. This comparator works as initially implemented by @SuXiChangZhen and handles this case, too.

I would re-use comparison code of EntryComparator, but not call EntryComparator, because the empty string handling is different.

@k3KAW8Pnf7mkmdSMPHz27
Copy link
Sponsor Member

Ok, nvm, ignore me, and my apologies for the confusion. I'll have to read up a bit more about merging.

@SuXiChangZhen
Copy link
Contributor Author

It seems that jabref will not produce a citation key like "" since if the citation key is "", then KEY_FIELD does not exist. But KEY_FIELD does allow something like " "(one blank), should I consider this case?

@SuXiChangZhen
Copy link
Contributor Author

I notice that in the BibEntry, the method getCitationKey indicates what is a valid ciatation key. So I use it in the EntryComparator. Now the blanked citation key will be replaced when merge two entries.

Copy link
Member

@Siedlerchr Siedlerchr left a comment

Choose a reason for hiding this comment

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

you can use orElse with Optionals

@@ -72,6 +72,9 @@ public int compare(BibEntry e1, BibEntry e2) {
// Sort by type.
f1 = e1.getType();
f2 = e2.getType();
} else if (sortField.equals(InternalField.KEY_FIELD)) {
f1 = e1.hasCitationKey() ? e1.getCitationKey().get() : null;
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
f1 = e1.hasCitationKey() ? e1.getCitationKey().get() : null;
f1 = e1.getCitationKey().orElse(null);
f2 = e2.getCitationKey().orElse(null);

@SuXiChangZhen
Copy link
Contributor Author

Thank you for your suggestion. I have used orElse.

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.

Thank you for working on it. Good to go for now to fix the concrete issue. We still need to think about the heuristics though.

We need to dig into our JabRef code base to fix some code quality issues - koppor#497

@koppor koppor merged commit edae432 into JabRef:main May 10, 2021
Siedlerchr added a commit that referenced this pull request May 15, 2021
* upstream/main: (71 commits)
  [Bot] Update CSL styles (#7735)
  Fix for issue 6966: open all files of multiple entries (#7709)
  Add simple unit tests (#7696)
  Add simple unit tests (#7543)
  Update check-outdated-dependencies.yml
  Added preset for new entry keybindings and reintroduced defaults (#7705)
  Select the entry which has smaller dictonary order when merge (#7708)
  Update CHANGELOG.md
  fix: make more fields, fomatters, ids and languages sorted by alphabetical order (#7717)
  Bump libreoffice from 7.1.2 to 7.1.3 (#7721)
  Bump unoloader from 7.1.2 to 7.1.3 (#7724)
  Bump org.beryx.jlink from 2.23.7 to 2.23.8 (#7723)
  Bump org.openjfx.javafxplugin from 0.0.9 to 0.0.10 (#7725)
  fix: make fields sorted by lexicographical order (#7711)
  Fix tests
  Refactoring existing unit tests (#7687)
  Refactoring and addition of unit tests (#7581)
  Refactor simple Unit Tests (#7571)
  Add simple unit tests (#7544)
  add and extend unit tests (#7685)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: changes required Pull requests that are not yet complete
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Possible Duplicates - Bibkey Comparison
4 participants