Purpose: API Refactoring Sprint
Date: March 13th/14th 2008
- Step through core services
- Admin - Ben
- <strike>Cohort - Darius</strike> Complete
- Concept - Dave
- Encounter - Brian
- Form - Darius
- Location - Brian
- <strike>Obs - Ben</strike> Complete
- Orders - Ben
- Patient - Burke
- PatientSet - (Ignored for now, will be refactored out eventually)
- Person - Burke
- <strike>ProgramWorkflow - Mike</strike> Complete
- <strike>User - Justin/Ben</strike> Complete
- Other services
- <strike> HL7 - Ben</strike> Complete
- <strike>Notification - Ben</strike> Complete
- Scheduler - (Ignored for now, will be refactored in scheduler branch by Justin)
- Util - ignored for now
- Logic - Ignored for now
- API refactoring in its own branch
- Hibernate issues
- Verify whether manipulating domain objects (Hibernate proxies) affects database? It shouldn't.
- Object passed to create() method adds ID to object – should use saveOrUpdate instead of merge (per Ben)
- Consistency across services (methods)
- Hibernate merge vs. save vs. update vs. persist vs. saveOrUpdate
- Do we return object or IDs?
- Decide on convention for Set vs. List vs. Collection
- Getting multiple objects with multiple methods w/ various number of parameters
- Take most stuff out of admin service (domain object specific methods move to their services)
- View from Groovy
- Move all date created and date changed from DAO level to API (service) level
- Verify if across all services, avoid overwriting (void and create new for each change)? What about person (can't change primary key)
- Add authorize annotations to API
- Add consistent log.info() calls to API methods:
- : log.info(Ã¢â‚¬Å“Creating location Ã¢â‚¬Å“ + location.getName());
- : log.info(Ã¢â‚¬Å“Updating location Ã¢â‚¬Å“ + location.getName());
- : log.info(Ã¢â‚¬Å“Deleting location Ã¢â‚¬Å“ + location.getName());
- Do we need includeVoided everywhere? If not, what's the convention/pattern for use across service methods?
- Does Location get its own service? What's the convention between service-per-region-of-model vs. service-per-domain-object?
- Ben Wolfe
- Brian McKown
- Burke Mamlin
- Paul Biondich
- Darius Jazayeri
- Mike Seaton
- Dave Thomas
- Justin Miranda
A documented, clean, consistent, and easy-to-use API layer.
- We will spend 75% of the two days writing/editing/documenting code, and 25% talking
- Any philosophical disagreements will be punted immediately — e.g., if agreeing on "voided" versus "retired" would take time, then weÃ¢â‚¬â„¢re not going to do it during this sprint
(All times in EDT)
- We answer all the high-level questions about what a service/impl/dao should look like.
- Together we go through ObsService, ObsServiceImpl, ObsDAO, and HibernateObsDAO, and fix that up as an example.
- At this point we will assign services to teams of 1-2 people.
- Each team gets a service, and cleans it up
- Reconvene as a big group, code review a few of the teamsÃ¢â‚¬â„¢ work, and show off any cool thoughts people had
- Re-split into teams, and do another round of services
API Refactoring branch: http://svn.openmrs.org/openmrs/branches/api_refactoring
Google Doc "whiteboard"
We should have a common template for all services in our API. This allows for easier comprehension and a cleaner codebase overall.
See the API Service Template that came out of this meeting.