I'm pretty sure sync converts all person attributes to their uuid equivalent already (and then back again). A similar thing could not be done for handlers easily. However, if we suggested that all handlers use uuids by default, then most would be ok.
Ben On Sep 26, 2011 8:48 PM, "Dave Thomas" <[email protected]> wrote: > Hi. Sorry to jump into this late, but I'm concerned about this new > attribute architecture with sync. > > If these custom handlers are serializing their objects using anything > but uuids for openmrs objects, sync is going to propagate mangled > data. That, or the custom handlers will have to be built into the > sync serialization process somehow to make sure that openmrsObject > references are uuid based. > > We get away with PersonAttributes at all currently because our > location tables all look the same between parent and child servers, > but in reality its already a precarious balance... > > d > > On Mon, Sep 26, 2011 at 5:56 AM, Burke Mamlin <[email protected]> wrote: >> I copied this e-mail onto this wiki page in case that helps anyone (Roger) >> in reviewing (commenting on) it. Anyone interested in this topic may want >> to watch that page as well as the associated ticket. >> -Burke >> >> On Sat, Sep 24, 2011 at 4:03 PM, Darius Jazayeri <[email protected]> >> wrote: >>> >>> Hi All, >>> On our last few design calls we've been working through the generic >>> AttributeType mechanism that we're introducing in 1.9. (see ticket) >>> I wanted to summarize the current state of things. Some of this is in >>> trunk, but some is refactoring I'm doing. I'm especially interested in >>> thoughts about how these classes should be linked together with >>> parameterized types, since I'm not convinced I've gotten that right: >>> interface CustomDatatypeHandler<T> >>> >>> Capable of converting T to/from a String that can be persisted in the >>> varchar column of a database. E.g. a date would be stored as yyyy-mm-dd and >>> an image might be stored as a uri pointing to a PACS system. Also capable of >>> validating T, e.g. so we can use a plain java.util.Date to represent >>> "date-in-past" but limit its possible values. >>> Defines a String "datatypeHandled", e.g. "date", "regex-validated-string") >>> T fromPersistedString(String) >>> String toPersistedString(T) >>> void validate(T) >>> String render(String persistedValue, String view) >>> can be configured with setHandlerConfiguration(String) >>> >>> interface CustomDatatyped >>> >>> holds the definition of a custom datatype (which is handled by a handler >>> of the above interface). For example VisitAttributeType and GlobalProperty >>> (we're able to do typed GPs trivially now) >>> required: String getDatatype() >>> optional: String getPreferredHandlerClassname() >>> >>> if specified, will be handled by this specific CustomDatatypeHandler, >>> otherwise it will be handled by the default handler for this thing's >>> datatype >>> >>> optional: String getHandlerConfig() >>> >>> interface AttributeType<OwningType extends Customizable> extends >>> CustomDatatyped, OpenmrsMetadata >>> >>> for user-defined extensions to core domain objects, which would be handled >>> by adding custom database columns in a less generic system. E.g. >>> VisitAttributeType implements AttributeType<Visit> >>> datatype/handler specified via CustomDatatyped superinterface >>> Integer getMinOccurs() >>> Integer getMaxOccurs() >>> >>> class VisitAttributeType, class LocationAttributeType, class >>> ProviderAttributeType >>> >>> trivial implementations of AttributeType (via BaseAttributeType) >>> >>> interface Customizable<AttrClass extends Attribute> >>> >>> Implemented by domain classes that may be customized by the user via >>> custom attributes. E.g. Visit implements Customizable<VisitAttribute>, >>> Location implements Customizable<LocationAttribute> >>> Has convenience methods for dealing with a collection of attributes, of >>> different types: >>> Collection<AttrClass> getAttributes() //includes voided >>> Collection<AttrClass> getActiveAttributes() //non-voided >>> void addAttribute(AttrClass) >>> void setAttribute(AttrClass) //voids other attributes of the given type >>> >>> interface CustomValue >>> >>> holds a value managed by a CustomDatatypeHandler. E.g. VisitAttribute, >>> GlobalProperty. Any implementation of this has a corresponding >>> CustomDatatyped implementation. "persistedValue" is a String suitable for >>> persisting in a db varchar column; "objectValue" is what you'd want to work >>> with in the API. >>> String getPersistedValue() >>> void setPersistedValue() >>> Object getObjectValue() // don't remember why this isn't <T> >>> void setObjectValue(Object) >>> >>> interface Attribute<OwningType extends Customizable> implements >>> CustomValue, OpenmrsData >>> >>> value corresponding to an AttributeType (which defines its datatype, >>> whether it's required, whether it can repeat, etc), e.g. VisitAttribute >>> corresponds to VisitAttributeType >>> OwningType getOwner() >>> void setOwner(OwningType) >>> AttributeType<OwningType> getAttributeType() >>> >>> class VisitAttribute, class LocationAttribute, class ProviderAttribute >>> >>> trivial implementation of Attribute (via BaseAttribute) >>> >>> class GlobalProperty implements CustomDatatyped, CustomValue >>> >>> this is interesting in that it both defines a custom datatype and stores >>> its value >>> >>> Thoughts welcome... >>> -Darius >>> ________________________________ >>> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> ________________________________ >> Click here to unsubscribe 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] _________________________________________ 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]
