We discussed this on yesterday's Design Forum/Call. https://wiki.openmrs.org/display/RES/Design+Forum http://notes.openmrs.org/Design-Forum-2011-09-07
I was unable to come up with a reason other than "the dev made a mistake and wants to undo it". We came to the conclusion that "case insensitive + case preserving" should be the way forward for global properties. I created this ticket for the work: https://tickets.openmrs.org/browse/TRUNK-2644 Ben On Tue, Sep 6, 2011 at 5:18 PM, Darius Jazayeri <[email protected]> wrote: > Ben, > Can you give an example where having case-sensitive global property names > would be useful? > (Personally I think that having "formentry.propertyA" and > "FormEntry.propertyA" be two different properties is actively bad, and there > are no cases where it'd be useful.) > -Darius > > On Tue, Sep 6, 2011 at 1:49 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) > <[email protected]> wrote: >> >> Did some quick research, found the following: >> >> MySQL: default collating sequence is not case sensitive, but any text >> column can be defined as case sensitive using the COLLATE clause; individual >> expressions can be made case sensitive by using COLLATE in the expression >> >> Postgres: comparison is case sensitive, case insensitivity in WHERE >> clauses achieved by using the LOWER() function; a supplied module provides >> the case-insensitive CITEXT datatype, which is more efficient because a >> CITEXT column can be indexed >> >> SQL Server: like MySQL >> >> Hibernate: there is no discussion of case sensitivity of text comparisons >> in the HQL WHERE clause or Restrictions.eq() method; manual only states that >> Criteria can be made case-insensitive via the .ignoreCase() method; there is >> some unofficial information that Hibernate will use the underlying DB's >> equal definition, some less reliable information that Hibernate will use the >> Java equals method appropriate to the object. >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Ben Wolfe >> Sent: Tuesday, September 06, 2011 2:52 AM >> To: [email protected] >> Subject: Re: [OPENMRS-DEV] OpenMRS 1.8.2 Released! >> >> I think the problem was that the api/hibernate was treating them as >> case insensitive but mysql was treating them as sensitive. So even if >> you had restModule and restmodule as GPs, you could never update one >> or the other. But its been a year and a half and I've forgotten the >> true reason. >> >> I do think we need to keep the column as case sensitive, but we should >> use the solution suggested by Saptarshi instead of using a varbinary. >> >> Ben >> >> On Tue, Sep 6, 2011 at 1:32 AM, Burke Mamlin <[email protected]> >> wrote: >> > Yeah. I can't remember the detail of TRUNK-94 and didn't do a decent >> > job of >> > describing it. I think the problem was that global properties were only >> > halfway case-sensitive. like you could find properties that didn't match >> > by >> > case, but couldn't change them. I don't know. It sure sounds like I'm >> > asking for case-sensitive global properties. I guess it's time for one >> > my >> > typical 180º turns. ;-) >> > Case-insensitive global properties makes sense to me - i.e., >> > case-insenstive, case-preserving. >> > -Burke >> > >> > On Sun, Sep 4, 2011 at 9:58 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) >> > <[email protected]> wrote: >> >> >> >> But who wants all our comparisons to be case sensitive? >> >> >> >> I'm with Darius, we should undo TRUNK-94 and say global variable names >> >> are >> >> case-insensitive. >> >> >> >> >> >> >> >> From: [email protected] [mailto:[email protected]] On Behalf Of Saptarshi >> >> Purkayastha >> >> Sent: Friday, September 02, 2011 3:32 PM >> >> >> >> To: [email protected] >> >> Subject: Re: [OPENMRS-DEV] OpenMRS 1.8.2 Released! >> >> >> >> >> >> >> >> >> >> >> >> http://confluence.atlassian.com/display/JIRAKB/Unable+to+Delete+Workflow+Due+to+MySQL+Case+Sensitivity >> >> >> >> >> >> >> >> I've just tried their suggested way and it works. So, when creating the >> >> database, if the collation is made to utf8_bin it all works fine. >> >> Understands case-sensitivity without having to make the column >> >> varbinary. >> >> >> >> --- >> >> Regards, >> >> Saptarshi PURKAYASTHA >> >> >> >> My Tech Blog: http://sunnytalkstech.blogspot.com >> >> You Live by CHOICE, Not by CHANCE >> >> >> >> On 22 July 2011 11:54, Ben Wolfe <[email protected]> wrote: >> >> >> >> IIRC, I tried that but mysql still didn't recognize it. The only way to >> >> get it to be case insensitive was to change the column type. >> >> >> >> Ben >> >> >> >> >> >> >> >> On Fri, Jul 22, 2011 at 1:54 AM, Saptarshi Purkayastha >> >> <[email protected]> >> >> wrote: >> >> >> >> I always thought case-sensitivity was determined by the collation. >> >> >> >> latin_general_ci where ci = case insensitive >> >> >> >> OR >> >> >> >> latin_general_cs where cs = case sensitive >> >> >> >> >> >> >> >> I don't understand why we have to change to binary for this?? >> >> >> >> --- >> >> Regards, >> >> Saptarshi PURKAYASTHA >> >> >> >> My Tech Blog: http://sunnytalkstech.blogspot.com >> >> You Live by CHOICE, Not by CHANCE >> >> >> >> On 22 July 2011 04:09, Darius Jazayeri <[email protected]> wrote: >> >> >> >> That sounds correct. >> >> >> >> >> >> >> >> -Darius >> >> >> >> >> >> >> >> PS- Burke, Ben, WTF is up with changing global_property.property to >> >> varbinary to make global property names case-sensitive? >> >> (https://tickets.openmrs.org/browse/TRUNK-94) I've been wondering why >> >> global_property.property shows up oddly in mysql workbench. 15 months >> >> later >> >> I'd like to say that I disagree. >> >> >> >> >> >> >> >> On Thu, Jul 21, 2011 at 2:44 PM, Burke Mamlin <[email protected]> >> >> wrote: >> >> >> >> Okay. A diff of 1.6.2 to 1.8.2 liquibase-update-to-latest.xml shows >> >> these >> >> as the structural changes: >> >> >> >> >> >> >> >> Added sort_weight column to concept_answers >> >> Renamed location_tag.tag to location_tag.name >> >> Changed global_property.property to varbinary(255) >> >> Switched boolean concepts to be stored as coded instead of numeric >> >> values >> >> Encounter & obs location can now be null >> >> Added active lists (active_list, active_list_type, active_list_allergy, >> >> & >> >> active_list_problem tables) >> >> Changed how concept names are handled >> >> >> >> Added concept_name.concept_name_type >> >> Added concept_name.locale_preferred >> >> Preferred names become "fully specified" names >> >> >> >> Require person_name.person_id >> >> Added location_id column to patient_program table >> >> Removed unused column (default_charge) from concept >> >> Switched to generic address columns (address3, address4, address5, >> >> address6) >> >> Added weight column to concept_word (not sure why that wasn't >> >> sort_weight) >> >> Removed concept_derived table >> >> >> >> @Ben/Darius - does that sound more correct? >> >> >> >> >> >> >> >> Cheers, >> >> >> >> >> >> >> >> -Burke >> >> >> >> >> >> >> >> On Thu, Jul 21, 2011 at 3:48 PM, Ben Wolfe <[email protected]> wrote: >> >> >> >> I think you've missed some things in there Burke. 1.6.2 came out after >> >> 1.7.0, so there are a lot of commits before 17887 that need to be >> >> included. >> >> >> >> I can't think of an easy way to do this automatically unless we start >> >> keeping a separate liquibase changelog file for each release...but then >> >> there a whole host of other problems with that. >> >> >> >> Visits are not in 1.8.2, are they? Same with form_resource... I think >> >> those are in because 1.8.2's revision number comes after a lot of >> >> commits to >> >> trunk (1.9). >> >> >> >> I think what you have to do is take the 1.8.2 >> >> liquibase-update-to-latest.xml and comare it to the 1.6.2 >> >> liquibase-update-to-latest.xml with a diff program. >> >> >> >> Ben >> >> >> >> On Thu, Jul 21, 2011 at 10:30 PM, Burke Mamlin >> >> <[email protected]> >> >> wrote: >> >> >> >> Looking at changes to liquibase-update-to-latest.xml from revision >> >> 17887 >> >> (1.6.2) to revision 21762 (1.8.2), I see these changes: >> >> >> >> Added patient_identifier_type.location_behavior >> >> patient_identifier.location_id can now be null. >> >> Added start_date and end_date to person_address >> >> Removed date_started & date_stopped from obs >> >> Added a form_resource table and moved form's xslt & template columns to >> >> it >> >> Added visits (visit, visit_type, visit_attribute, & >> >> visit_attribute_type >> >> tables) >> >> Added start & end dates to relationships >> >> >> >> -Burke >> >> >> >> >> >> >> >> On Thu, Jul 21, 2011 at 2:20 PM, Yeung, Ada K. <[email protected]> >> >> wrote: >> >> >> >> Thanks for the update and release of 1.8.2! >> >> >> >> >> >> >> >> I would like to know the difference between the 1.6 data model and 1.8 >> >> data model. I can't find such info on the released notes. Also, when >> >> will >> >> 1.8 data model be available on OpenMRS wiki? >> >> >> >> >> >> >> >> --Ada >> >> >> >> >> >> >> >> From: [email protected] [mailto:[email protected]] On Behalf Of Wyclif >> >> Luyima >> >> Sent: Wednesday, July 20, 2011 6:40 PM >> >> To: [email protected] >> >> Subject: [OPENMRS-DEV] OpenMRS 1.8.2 Released! >> >> >> >> >> >> >> >> Hello everyone, >> >> >> >> >> >> >> >> We are proud to announce that the maintenance release OpenMRS 1.8.2 is >> >> now >> >> available. >> >> >> >> This is a maintenance release in the OpenMRS 1.8.x line, specifically >> >> to >> >> fix a high-priority bug introduced in 1.8.1. If you are currently >> >> running >> >> 1.8.1, we recommend that you upgrade as soon as possible. There are no >> >> database changes between OpenMRS 1.8.1 and OpenMRS 1.8.2. It is fully >> >> backwards and forwards compatible. >> >> >> >> The three bug fixes in this release are: >> >> >> >> (Major) The "last 3 encounters" box on the form entry tab of the >> >> patient >> >> dashboard was actually showing the first 3 encounters. >> >> The concept statistics page was fixed to display statistics for numeric >> >> concepts. >> >> Resolved Conflicting ASM Library >> >> >> >> >> >> >> >> We recommend upgrading to 1.8.2 for those with an existing installation >> >> of >> >> OpenMRS. >> >> >> >> >> >> >> >> Download: OpenMRS 1.8.2 Download. >> >> >> >> >> >> >> >> Release Notes: OpenMRS 1.8.2 Release Notes >> >> >> >> >> >> >> >> Thanks to everyone who has contributed to making this release a >> >> success. >> >> >> >> >> >> >> >> Kind Regards >> >> >> >> >> >> >> >> -Wyclif >> >> >> >> >> >> >> >> ________________________________ >> >> >> >> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> >> >> >> >> >> >> ________________________________ >> >> >> >> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> >> >> >> >> >> >> ________________________________ >> >> >> >> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> >> >> >> >> >> >> >> >> >> >> ________________________________ >> >> >> >> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> >> >> >> >> >> >> >> >> >> >> ________________________________ >> >> >> >> 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] > > ________________________________ > 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]
