Open gracebrownecodes opened 10 years ago
Depending on how much differs, this could be done one of two ways:
pedsnet_harvest
as an app that overrides various parts of omop_harvest
(templates, static files, urls, etc.)(1) Is definitely preferred since there is clear separation and no redundancy between the two repositories, but we need to assess how deep the changes go. Mind listing out the changes you are aware of?
Here are the differences I can see at the moment:
pedsnet_harvest |
omop_harvest |
---|---|
pedsnet landing page | land on query page |
force_script_name | run at root |
chop_auth w/ AD | no authentication |
registration | no registration |
data access auth by org | no data access auth |
query logging | no query logging |
deploy with cbmi_utils | straight docker deploy |
based on internal django_baseimage | based on phusion_baseimage |
db connection with ssl | no ssl to database |
Ok, all of that is standard stuff. It would be worth evaluating omop_harvest
to delineate which parts make up the library vs. the parts that make it a deployable application. They are generally completely separate.
I see three logical repositories here:
omop_harvest
app which contains the data model, formatters, etc. custom stuff applicable to the OMOP domainomop_harvest
already included for convenience and can be stood quickly (e.g. harvest init omop
)pedsnet_harvest
application which is a "project instance" that uses omop_harvest
(the app) and includes some of it's own custom stuffVarify is an example of this and can be used a drop-in Django app or a standalone project. Our chop_varify
application uses Varify as an app and provides a minimal set of configuration and code to customize it for our internal needs.
I think it has come time to officially divorce the two projects, because they are really separate. Although much of the development on pedsnet_harvest will probably apply to omop_harvest, enough differences exist to make the split desirable, in my opinion. Thoughts?