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] > _________________________________________ 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]
