Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Install
-
Labels:None
-
Environment:not applicable
-
Rank:0|i0010v:
Description
I am new to i2b2 and have done 3 installs in the last few weeks. The first 2 were development installs, the last was a pre-production install. Here are the biggest gotchas or gaps from my perspective:
1). There are 'application' settings being compiled as 'build' settings (like database connection strings). These true app settings need to be removed from the build process. There are many ways this can be done - if someone has a question on this they can email me. Bottom line: folder locations and db connections should NEVER be compiled into a .class or .jar or .ear file. These setting values can change and it makes roll-backs and recoveries much more difficult if they are 'hard wired'.
2). There are too many configuration files given the actual values that must be changed. First, it is always best to separate configuration from build variables (these seem mixed). With more places to copy/paste (or script) the likelihood of error increases. I think, for all the files I have had to edit, the following represent the only real settings: DBConnection (should be an app setting or modifiable setting, Service Locations, App Locations, Folder locations. There are other settings but really, these are the main ones from an error/build perspective. I think it would be good to rationalize these.
3). There needs to be a data dictionary for i2b2.
4). The documentation needs work. There are too many gaps and too much redundancy (in this case the redundancy is likely to cause error and not prevent it).
I really do want i2b2 to succeed, but I must admit that most (if not all) the issues I have identified so far are build/deployment related. This should not be the case and it is very problematic to convince people to jump on board a system when this is true.
Cheers!
:)
1). There are 'application' settings being compiled as 'build' settings (like database connection strings). These true app settings need to be removed from the build process. There are many ways this can be done - if someone has a question on this they can email me. Bottom line: folder locations and db connections should NEVER be compiled into a .class or .jar or .ear file. These setting values can change and it makes roll-backs and recoveries much more difficult if they are 'hard wired'.
2). There are too many configuration files given the actual values that must be changed. First, it is always best to separate configuration from build variables (these seem mixed). With more places to copy/paste (or script) the likelihood of error increases. I think, for all the files I have had to edit, the following represent the only real settings: DBConnection (should be an app setting or modifiable setting, Service Locations, App Locations, Folder locations. There are other settings but really, these are the main ones from an error/build perspective. I think it would be good to rationalize these.
3). There needs to be a data dictionary for i2b2.
4). The documentation needs work. There are too many gaps and too much redundancy (in this case the redundancy is likely to cause error and not prevent it).
I really do want i2b2 to succeed, but I must admit that most (if not all) the issues I have identified so far are build/deployment related. This should not be the case and it is very problematic to convince people to jump on board a system when this is true.
Cheers!
:)