-
Notifications
You must be signed in to change notification settings - Fork 243
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
Implements collections of bundles. #1702
Conversation
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.
A few little issues.
I recommend we change from returning bundle Collection to bundle List. It's rare we actually want an unsorted bag of file names.
@@ -38,7 +38,9 @@ | |||
public class Bundle implements Iterable<BundleResource>, Serializable { | |||
private static final long serialVersionUID = 1L; | |||
|
|||
private final Map<String, BundleResource> resources = new LinkedHashMap<>(); | |||
// don't use LinkedHashMap here; using HashMap resolves unnatural resource ordering issues that arise |
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.
I'm not sure I follow what's going on here when you have a LinkedHashMap. Shouldn't serializing a linked hashmap deserialize it to the same map?
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.
Hm. I was having problems when roundtripping these through JSON, but I can no longer reproduce the issue, so reverting to our beloved LinkedHashMap.
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.
Long Live LinkedHashMap!
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.
So I realized what the issue was here. JSONObject
internally uses a HashMap
(implying, I think, that JSON doesn't preserve the serialized order of JSON attributes), so when you roundtrip through JSON, the iteration order from JSON is based on the HashMap
order. If we use LinkedHashMap
in Bundle
, then the order after a roundtrip gets scrambled, and tests fail (but only for some cases because sometimes the roundtrip order matches and sometimes it differs).
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.
Ahah, that makes sense. Seems like a weird decision to not maintain internal order, but it's good to know about. Cana we change our tests to use an order independent comparison?
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.
I added an resource-order-independent equals method for use in the tests.
public static final String JSON_SCHEMA_NAME = "htsbundle"; | ||
public static final String JSON_SCHEMA_VERSION = "0.1.0"; // TODO: bump this to 1.0.0 | ||
|
||
final private static Set<String> TOP_LEVEL_PROPERTIES = Collections.unmodifiableSet( | ||
new HashSet<String>() { | ||
new HashSet<>() { |
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.
Can these static declarations be migrated to use Set.of()
instead of these anonymous classes?
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.
Oh yeah, thats an improvement. Done.
final Collection<Bundle> bundles = toBundleCollection(jsonString, ioPathConstructor); | ||
if (bundles.size() > 1) { | ||
throw new IllegalArgumentException( | ||
String.format("A JSON string with more than one bundle was provided but only a single Bundle is allowed", |
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.
The format string is missing the template variables.
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.
Oh, fixed.
} | ||
} | ||
if (bundles.size() < 1) { |
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.
Nitpicky but I isEmpty might be better
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.
Done.
final String primaryContentType = getRequiredPropertyAsString(jsonObject, JSON_PROPERTY_PRIMARY); | ||
final Collection<BundleResource> bundleResources = toBundleResources(jsonObject, ioPathConstructor); | ||
if (bundleResources.isEmpty()) { | ||
LOG.warn("Empty resource bundle found in: ", jsonObject.toString()); |
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.
Should we allow empty bundles at all?
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.
Actually, we already don't. I'll remove this (the Bundle
constructor will throw anyway), and add a negative test to BundleTest
to demonstrate that.
return new IOPathResource( | ||
ioPathConstructor.apply(getRequiredPropertyAsString(jsonObject, JSON_PROPERTY_PATH)), | ||
contentType, | ||
format == null ? null : format); |
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.
I think this ternary is unnecessary since you're not dereferencing format here.
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.
Fixed.
"}\n", | ||
BundleResourceType.ALIGNED_READS, | ||
Arrays.asList(BundleResourceTestData.readsWithFormat) | ||
""" |
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.
This is SO much nicer.
@@ -30,11 +32,12 @@ public class BundleJSON { | |||
public static final String JSON_PROPERTY_PRIMARY = "primary"; | |||
public static final String JSON_PROPERTY_PATH = "path"; | |||
public static final String JSON_PROPERTY_FORMAT = "format"; | |||
|
|||
public static final String JSON_SCHEMA_NAME = "htsbundle"; | |||
public static final String JSON_SCHEMA_VERSION = "0.1.0"; // TODO: bump this to 1.0.0 |
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.
Should this be 0.2.0 now?
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.
Will update the schema in a separate PR when I move the bundle classes out of the beta package.
* @return Collection<Bundle> | ||
* @param <T> IOPath-derived class to use for IOPathResources | ||
*/ | ||
public static <T extends IOPath> Collection<Bundle> toBundleCollection( |
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.
Do we really want this to be Collection and not something with an order? I would think List might be better? The input order is usually important in some way, changing the encounter order can often change either errors generated or floating point aggregations even if it's something that seems like it should be file order agnostic.
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.
Changed to Lists.
437912b
to
1be2b85
Compare
1be2b85
to
8b0e589
Compare
bf33fee
to
79ba8d9
Compare
@lbergelson I updated the names and organization of the bundle content type strings in this, which is why there are now so many changes. |
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.
@cmnbroad Looks good to me. I'm not 100% sure why you want to decouple the content type names from the enums but that seems fine.
Also contains some commits with minor updates to take advantage of Java 17 and Java text blocks.