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]<mailto:[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]<mailto:[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]<mailto:djazayeri%[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]<mailto:[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<http://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]<mailto:[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]<mailto:[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]<mailto:[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<https://wiki.openmrs.org/download/attachments/589829/Openmrs_data_model_1.6.png> 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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Wyclif Luyima Sent: Wednesday, July 20, 2011 6:40 PM To: [email protected]<mailto:[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<http://sourceforge.net/projects/openmrs/files/releases/OpenMRS_1.8.2/openmrs.war/download>. Release Notes: OpenMRS 1.8.2 Release Notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.8.2> Thanks to everyone who has contributed to making this release a success. Kind Regards -Wyclif ________________________________ 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 ________________________________ 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 ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
