Technical Workshop 3 13-3 14 2008

Owned by Former user (Deleted)
Last updated: Aug 25, 2010 by Michael DowneyVersion comment
2 min read

<html><head><title></title></head><body><div style="float:right">

</div>

Purpose: API Refactoring Sprint
Location: Virtual

Date: March 13th/14th 2008

Issues

  • 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?

Attendees

  • Ben Wolfe

  • Brian McKown

  • Burke Mamlin

  • Paul Biondich

  • Darius Jazayeri

  • Mike Seaton

  • Dave Thomas

  • Justin Miranda

  • ...?

Primary Goal

A documented, clean, consistent, and easy-to-use API layer.

Principles

  1. We will spend 75% of the two days writing/editing/documenting code, and 25% talking

  2. 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

Agenda

(All times in EDT)

  • 9am-11am

    • 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.

  • 11am-2pm

    • At this point we will assign services to teams of 1-2 people.

    • Each team gets a service, and cleans it up

  • 2pm-3pm

    • Reconvene as a big group, code review a few of the teams’ work, and show off any cool thoughts people had

  • 3pm-5pm

    • Re-split into teams, and do another round of services

Notes

API Refactoring branch: http://svn.openmrs.org/openmrs/branches/api_refactoring

Google Doc "whiteboard"

Output

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.

</body></html>