I don't think it has any special handling for global properties. Global properties aren't sync'ed by default, and we haven't changed that default on our servers in Haiti.
Mark From: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Monday, September 26, 2011 3:08 PM To: [email protected] Subject: Re: [OPENMRS-DEV] Current state of attributes Good point Dave. The problem is that (and Roger mentioned this somewhere) the db and hibernate metadata don't know that the "3" stored in a visit_attribute.value column is supposed to be FKd to location (or whatever). One option is what Ben says: force all custom datatype handlers to use uuids. The other option would be that sync does a special-case for anything that implements CustomValue and whose typed value is an OpenmrsObject. (I can see how that would be able to convert to uuid when you record the changeset. But I don't know how you'd convert back from uuid when applying the changeset elsewhere.) How does sync currently handle things like global_property that frequently have ids stored as text? -Darius On Mon, Sep 26, 2011 at 11:33 AM, Ben Wolfe <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> with "SIGNOFF > openmrs-devel-l" in the body (not the subject) of your e-mail. > > [mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l] ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[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]
