I don't like the idea of just putting our database connection out there for devs to muck with. I fear they would tend to see that and start to modify things directly instead of going through the api methods. Offering the db connection up at the service layer also feels like a violation of the separation of layers.
A module could expose the connection for itself by creating a service/dao and passing it back up. The web startup and wizards do not have access to the api. The spring services do not start until the database is fully set up and upgraded. So if we were to try to consolidate the place where these all get the db connection, the admin service couldn't be it. It will need to be some sort of factory or util method. Ben On Tue, Aug 16, 2011 at 1:04 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > In looking at the Jasper Reports module, I see that it needs a jdbc > connection to pass to the Jasper report generator. The way it is coded, it > accepts only MySQL because that is the only driver name that it knows.**** > > I'm pretty sure BIRT also needs a DB connection, but I think the BIRT > module has avoided the need for BIRT to access the OpenMRS DB by writing an > intermediate output file to a known location for the BIRT report generator > to use with a text driver. This is slower than accessing the DB directly > (but may have other advantages).**** > > It seems reasonable that there would be other modules that need a jdbc > connection to the DB, MIRTH and deduplicate jump into mind immediately. > They should be provided with the means of getting/making a connection to any > supported OpenMRS database. I don't think we want to share our primary > connection; for example, we might want to run a MIRTH connection at a lower > priority than our own. **** > > We are already doing this process several times in trunk (in the > Wizard, in the non-web startup routine, in the DB updater (where it's used > by Liquibase), in the web startup routine). The most complete process is > found in DatabaseUtil:loadDatabaseDriver to load the appropriate driver, > either by reading an optional runtime property or by finding a known DB in > the DB URL runtime property; but this is not exposed through the Admin > Service. The DB URL property seems to be set once it is found (messing > around inside the user's file system). However, we use the connection > information available through Hibernate properties to get the driver class > and dialect. **** > > I would suggest that we create a sort of factory class (make an > instance available through the Admin Service?) that uses the properties file > and the logic of loadDatabaseDriver to get the driver information and has > methods to get a jdbc parameter (driver class, DBURL, username, password, > dialect?) or a new connection. We should use it consistently in trunk > code. Then we should check the modules to make sure that they are using > this rather than supporting only MySQL.**** > > Thoughts?**** > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
