Wes Brown

Thanks for the detailed explanation! I can understand why you chose composition over inheritance but wonder if it would be helpful to actually use both; define the ExtraDataEntity as you already do...

Thanks for the detailed explanation! I can understand why you chose composition over inheritance but wonder if it would be helpful to actually use both; define the ExtraDataEntity as you already do and then also define the BaseExtraDataEntity (or whatever) with the field and import/export logic already defined for the majority of the classes to use (except Orderable).

I am just looking for ways to reduce the duplication of the field and import/export logic in each domain class and this seems to provide that. I'm open to thoughts about whether this is worth the effort though.

Is there a reason why this isn't being designed as a sub-class of `BaseEntity`? It seems more natural (from an Object Oriented design perspective) for domain objects to be inherit from a base class...

Is there a reason why this isn't being designed as a sub-class of `BaseEntity`? It seems more natural (from an Object Oriented design perspective) for domain objects to be inherit from a base class which contains the appropriate fields. In this case, I would expect that the concrete domain classes that include extra data would simply use this class as the base class.

This extraData field is continuing to get used but the logic (limited as it is) is being copied by each domain/dto object. I think that a BaseEntity and BaseDto subclass should be created with the ...

This extraData field is continuing to get used but the logic (limited as it is) is being copied by each domain/dto object. I think that a BaseEntity and BaseDto subclass should be created with the extraData field and associated logic (import, export, etc) that domain/dto objects could inherit from instead of BaseEntity/BaseDto.

The properties defined in this interface don't seem to have anything specific to do with a FHIR resource and so the name of this interface seems misleading. This interface just represents an extens...

The properties defined in this interface don't seem to have anything specific to do with a FHIR resource and so the name of this interface seems misleading. This interface just represents an extensible (extendable?) entity, which is required for a FHIR resource but not specific to one.

This `extraData` design is in use in a few domain classes with identical annotations. Can this be abstracted into a base class that domain objects can inherit and not have to repeat the definition ...

This `extraData` design is in use in a few domain classes with identical annotations. Can this be abstracted into a base class that domain objects can inherit and not have to repeat the definition each time? Likewise, the importer and exporter interfaces could be extended to include this field.

Are you expecting to reuse this method? It doesn't look like you are currently using it anywhere other than the synchronize method and I'm not sure there is value in moving this small code block to...

Are you expecting to reuse this method? It doesn't look like you are currently using it anywhere other than the synchronize method and I'm not sure there is value in moving this small code block to its own method.

I thought that we were going to look at sharing some of the common settings/configurations in the jenkins files. It seems unfortunate to have to update this for every service when the setting is th...

I thought that we were going to look at sharing some of the common settings/configurations in the jenkins files. It seems unfortunate to have to update this for every service when the setting is the same across them all.

Given this, I'm not going to dig too far into this.

Given this, I'm not going to dig too far into this.

Assuming adding this content to the message is correct (as per Brandon's comment), you should add a space between the '.' and 'The...'

Assuming adding this content to the message is correct (as per Brandon's comment), you should add a space between the '.' and 'The...'

Rather than having to define, load, and insert each csv file individually, is it possible to just load all the csv files in the specified folder and insert them using some kind of structured file n...

Rather than having to define, load, and insert each csv file individually, is it possible to just load all the csv files in the specified folder and insert them using some kind of structured file name (or something) to map the file to a table?

Are these type of path's and known files stored in a constants class somewhere rather than being used as magic strings?

Are these type of path's and known files stored in a constants class somewhere rather than being used as magic strings?