Retrieving openmrs metadata by name

classic Classic list List threaded Threaded
15 messages Options
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Retrieving openmrs metadata by name

Hi all,

Lu brings up a good point below, which is - once we add localization to the names of our BaseOpenmrsMetadata objects, how do we want Service methods such as EncounterService.getEncounterType(String name) to behave?

My assumption is that we will want to check to see if any localized name matches on each EncounterType.  So, if we have:

EncounterType:
 id: 1
 names: {en="HIV Intake", fr="VIH Donnees de Base"}

Then both "HIV Intake" or "VIH Donnees de Base" can be passed to EncounterService.getEncounterType(String name) in order to retrieve this EncounterType, regardless of the user's current locale.

Does anyone have another take on the expected behavior?

As an additional note, it seems that we have no unique constraints on our Metadata names.  So, for example, it is possible for me to create 2 different Encounter Types with the same name using the administration pages.  Given this, how do we expect the getEncounterType(String name) method to behave?  Right now, my guess is that Hibernate is just returning the first match found, but I'd think we would want our API to be smarter than this...

Thanks,
Mike


On 05/11/10 09:01, Lu Zhuangwei wrote:
Hi, Mike

When I am reading related codes for my project, I found that once I have modified "name" property of BaseOpenmrsMetadata to "localizedName", then I also need to modify those related methods in Hibernate*DAO, except from I need to map "localizedName" to "name" column in *.hbm.xml files.

Such as in method "getEncounterType(String name)" in "HibernateEncounterDAO":

    public EncounterType getEncounterType(String name) throws DAOException {
          Criteria crit = sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
          crit.add(Expression.eq("retired", false));
          crit.add(Expression.eq("name", name));
          EncounterType encounterType = (EncounterType) crit.uniqueResult();
    }

I think we should change the query logic in this method and now as the "localizedName" is of type LocalizedString, so I think we cann't only use such easy query manner like  "Expression.eq(...)" any more. 

In this email, I just want to confirm that we need to resolve such a underlying problem, but how to resolve it, I think we can discuss in summer. Do you think so?


Lu

--
Zhuangwei Lu(陆庄伟)
Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)

[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe Ben Wolfe
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
helper method in HibernateUtil to do the criteria easily would be nice
to have.

A ticket is out there to prevent multiple names for metadata.
http://dev.openmrs.org/ticket/872  This is an API level check, not a db
constraint because we can have duplicate names for voided metadata but
only one name for non-voided metadata.

Ben

On 05/11/2010 10:01 AM, Michael Seaton wrote:

> Hi all,
>
> Lu brings up a good point below, which is - once we add localization to
> the names of our BaseOpenmrsMetadata objects, how do we want Service
> methods such as EncounterService.getEncounterType(String name) to behave?
>
> My assumption is that we will want to check to see if any localized name
> matches on each EncounterType. So, if we have:
>
> EncounterType:
> id: 1
> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>
> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
> EncounterService.getEncounterType(String name) in order to retrieve this
> EncounterType, regardless of the user's current locale.
>
> Does anyone have another take on the expected behavior?
>
> As an additional note, it seems that we have no unique constraints on
> our Metadata names. So, for example, it is possible for me to create 2
> different Encounter Types with the same name using the administration
> pages. Given this, how do we expect the getEncounterType(String name)
> method to behave? Right now, my guess is that Hibernate is just
> returning the first match found, but I'd think we would want our API to
> be smarter than this...
>
> Thanks,
> Mike
>
>
> On 05/11/10 09:01, Lu Zhuangwei wrote:
>> Hi, Mike
>>
>> When I am reading related codes for my project, I found that once I
>> have modified "name" property of BaseOpenmrsMetadata to
>> "localizedName", then I also need to modify those related methods in
>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>> column in *.hbm.xml files.
>>
>> Such as in method "getEncounterType(String name)" in
>> "HibernateEncounterDAO":
>>
>> public EncounterType getEncounterType(String name) throws DAOException {
>> Criteria crit =
>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>> crit.add(Expression.eq("retired", false));
>> crit.add(Expression.eq("name", name));
>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>> }
>>
>> I think we should change the query logic in this method and now as the
>> "localizedName" is of type LocalizedString, so I think we cann't only
>> use such easy query manner like "Expression.eq(...)" any more.
>>
>> In this email, I just want to confirm that we need to resolve such a
>> underlying problem, but how to resolve it, I think we can discuss in
>> summer. Do you think so?
>>
>>
>> Lu
>>
>> --
>> Zhuangwei Lu(陆庄伟)
>> Mobile: +86 151-0103-7842
>> MSN: [hidden email] <mailto:[hidden email]>
>> Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius

On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list
luzhuangwei luzhuangwei
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

Hi, Mike

Thank you very much for moving the email thread here:-)

Hi, All

Thanks for your helpful comments.

Here I have questions about ticket#872. I have seen the patch for this ticket, as now I think the validate logic for duplicate metadata name is ok. But when we support metadata's localization, we have to modify the validate logic. So I want to know the new condition for "judge duplicate metadata name":

1. names are identical in at least one locale(e.g., Context.getLocale()) for two different metadata, then we think they are duplicate.   
    Here is a example for above condition:
    EncounterType1.name -> {en="Hello"; es="Hola"}
    EncounterType2.name -> {en="Hello"; es="Not same"}

2. names are identical in all locales for two differrent metadata, then we think they are duplicate.
    Here is a example for above condition:
    EncounterType1.name -> {en="Hello"; es="Hola"}
    EncounterType2.name -> {en="Hello"; es="Hola"}

Which condition is suitable? described in #1 or #2? 

Also I am not sure whether I need to fulfill this feature(validate duplicate metadata name) in my project, or fulfill it after summer?



Lu


On Wed, May 12, 2010 at 12:29 AM, Darius Jazayeri <[hidden email]> wrote:
I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius


On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)
Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)

[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

(1) is a duplicate.

-Darius

On Tue, May 11, 2010 at 11:23 AM, Lu Zhuangwei <[hidden email]> wrote:
Hi, Mike

Thank you very much for moving the email thread here:-)

Hi, All

Thanks for your helpful comments.

Here I have questions about ticket#872. I have seen the patch for this ticket, as now I think the validate logic for duplicate metadata name is ok. But when we support metadata's localization, we have to modify the validate logic. So I want to know the new condition for "judge duplicate metadata name":

1. names are identical in at least one locale(e.g., Context.getLocale()) for two different metadata, then we think they are duplicate.   
    Here is a example for above condition:
    EncounterType1.name -> {en="Hello"; es="Hola"}
    EncounterType2.name -> {en="Hello"; es="Not same"}

2. names are identical in all locales for two differrent metadata, then we think they are duplicate.
    Here is a example for above condition:
    EncounterType1.name -> {en="Hello"; es="Hola"}
    EncounterType2.name -> {en="Hello"; es="Hola"}

Which condition is suitable? described in #1 or #2? 

Also I am not sure whether I need to fulfill this feature(validate duplicate metadata name) in my project, or fulfill it after summer?



Lu


On Wed, May 12, 2010 at 12:29 AM, Darius Jazayeri <[hidden email]> wrote:
I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius


On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)

Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

In reply to this post by Darius Jazayeri-3
So, name uniqueness is only applied within a locale; a match in the current locale always wins amongst other matches; and, in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?

-Burke

On May 11, 2010, at 12:29 PM, Darius Jazayeri wrote:

I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius

On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

That sounds good to me.

-Darius

On Tue, May 11, 2010 at 6:36 PM, Burke Mamlin <[hidden email]> wrote:
So, name uniqueness is only applied within a locale; a match in the current locale always wins amongst other matches; and, in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?

-Burke

On May 11, 2010, at 12:29 PM, Darius Jazayeri wrote:

I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius

On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
luzhuangwei luzhuangwei
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

In reply to this post by Darius Jazayeri-3
Darius:

Thanks for your reply. Ok, I got it now. As your meaning, the condition (1) is suitable for judging duplicate metadata name.


Lu

On Wed, May 12, 2010 at 3:09 AM, Darius Jazayeri <[hidden email]> wrote:
(1) is a duplicate.

-Darius


On Tue, May 11, 2010 at 11:23 AM, Lu Zhuangwei <[hidden email]> wrote:
Hi, Mike

Thank you very much for moving the email thread here:-)

Hi, All

Thanks for your helpful comments.

Here I have questions about ticket#872. I have seen the patch for this ticket, as now I think the validate logic for duplicate metadata name is ok. But when we support metadata's localization, we have to modify the validate logic. So I want to know the new condition for "judge duplicate metadata name":

1. names are identical in at least one locale(e.g., Context.getLocale()) for two different metadata, then we think they are duplicate.   
    Here is a example for above condition:
    EncounterType1.name -> {en="Hello"; es="Hola"}
    EncounterType2.name -> {en="Hello"; es="Not same"}

2. names are identical in all locales for two differrent metadata, then we think they are duplicate.
    Here is a example for above condition:
    EncounterType1.name -> {en="Hello"; es="Hola"}
    EncounterType2.name -> {en="Hello"; es="Hola"}

Which condition is suitable? described in #1 or #2? 

Also I am not sure whether I need to fulfill this feature(validate duplicate metadata name) in my project, or fulfill it after summer?



Lu


On Wed, May 12, 2010 at 12:29 AM, Darius Jazayeri <[hidden email]> wrote:
I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius


On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)

Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)
Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)

[hidden email] from OpenMRS Developers' mailing list
luzhuangwei luzhuangwei
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

In reply to this post by Burke Mamlin
Burke:

Thanks for your reply. I got it, so as you said, name uniqueness is only applied within a locale. So once we find two encounterTypes have a same name in just one locale, then we will consider they are duplicate.

But, I can't understand this sentence "in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?" What dose it mean?


Lu


On Wed, May 12, 2010 at 9:36 AM, Burke Mamlin <[hidden email]> wrote:
So, name uniqueness is only applied within a locale; a match in the current locale always wins amongst other matches; and, in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?

-Burke


On May 11, 2010, at 12:29 PM, Darius Jazayeri wrote:

I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius

On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)
Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)

[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

He's talking about the rare case where you have:

en:Alpha, fr:Bravo
en:Xray, fr:Bravo

and then you are in locale=en and you search for "Bravo".

-Darius


On Tue, May 11, 2010 at 9:57 PM, Lu Zhuangwei <[hidden email]> wrote:
Burke:

Thanks for your reply. I got it, so as you said, name uniqueness is only applied within a locale. So once we find two encounterTypes have a same name in just one locale, then we will consider they are duplicate.

But, I can't understand this sentence "in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?" What dose it mean?


Lu



On Wed, May 12, 2010 at 9:36 AM, Burke Mamlin <[hidden email]> wrote:
So, name uniqueness is only applied within a locale; a match in the current locale always wins amongst other matches; and, in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?

-Burke


On May 11, 2010, at 12:29 PM, Darius Jazayeri wrote:

I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius

On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)

Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
luzhuangwei luzhuangwei
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

Darius:

Ah, I got it now. Thanks a lot! So, as Burke's suggestion, we should return the first found obj. In your example, it is "en:Alpha, fr:Bravo".

But I wonder why we allow these two objects exist simultaneously?  As my understanding about the validate logic for duplicate metadata name, I think the second object "en:Xray, fr:Bravo" won't be saved into database successfully, result from a duplicate name ("fr: Bravo").


Hmm, I think maybe this use case can describe what Burke said:

fr: Bravo,it: Italiy
fr: Hello, it: Bravo

and then you are in locale=en and you search for "Bravo".



Lu



On Wed, May 12, 2010 at 1:01 PM, Darius Jazayeri <[hidden email]> wrote:
He's talking about the rare case where you have:

en:Alpha, fr:Bravo
en:Xray, fr:Bravo

and then you are in locale=en and you search for "Bravo".

-Darius


On Tue, May 11, 2010 at 9:57 PM, Lu Zhuangwei <[hidden email]> wrote:
Burke:

Thanks for your reply. I got it, so as you said, name uniqueness is only applied within a locale. So once we find two encounterTypes have a same name in just one locale, then we will consider they are duplicate.

But, I can't understand this sentence "in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?" What dose it mean?


Lu



On Wed, May 12, 2010 at 9:36 AM, Burke Mamlin <[hidden email]> wrote:
So, name uniqueness is only applied within a locale; a match in the current locale always wins amongst other matches; and, in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?

-Burke


On May 11, 2010, at 12:29 PM, Darius Jazayeri wrote:

I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius

On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)

Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)
Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)

[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

In reply to this post by Darius Jazayeri-3
Actually, not quite.  Names should be unique within a locale, so there should never be a case where two of the same types of metadata have the name "Bravo" in the same (fr) locale.

So,

en:Alpha, fr:Bravo
en:Xray, fr_rw:Bravo

-Burke

fr_rw = Rawandan French

On May 12, 2010, at 1:01 AM, Darius Jazayeri wrote:

He's talking about the rare case where you have:

en:Alpha, fr:Bravo
en:Xray, fr:Bravo

and then you are in locale=en and you search for "Bravo".

-Darius


On Tue, May 11, 2010 at 9:57 PM, Lu Zhuangwei <[hidden email]> wrote:
Burke:

Thanks for your reply. I got it, so as you said, name uniqueness is only applied within a locale. So once we find two encounterTypes have a same name in just one locale, then we will consider they are duplicate.

But, I can't understand this sentence "in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?" What dose it mean?


Lu



On Wed, May 12, 2010 at 9:36 AM, Burke Mamlin <[hidden email]> wrote:
So, name uniqueness is only applied within a locale; a match in the current locale always wins amongst other matches; and, in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?

-Burke


On May 11, 2010, at 12:29 PM, Darius Jazayeri wrote:

I think there are several common use cases where we do want to return names that match in other locales:
* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)
* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)
* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

-Darius

On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:
Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke

> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --
>>> Zhuangwei Lu(½ׯΰ)
>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>
>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)

Mobile: +86 151-0103-7842
MSN: [hidden email]
Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

Burke, can we really guarantee this?  For example, if we have two diagnoses, "HIV Infection" and "AIDS", and usage in the locale is that AIDS is only a synonym for advanced HIV infection, reflected in the diagnosis plus the staging, we do get Darius' use case.  Likewise with TB, there are lots of ways to have extrapulmonary TB, only some will be named.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Wednesday, May 12, 2010 9:25 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Retrieving openmrs metadata by name

 

Actually, not quite.  Names should be unique within a locale, so there should never be a case where two of the same types of metadata have the name "Bravo" in the same (fr) locale.

 

So,

 

en:Alpha, fr:Bravo

en:Xray, fr_rw:Bravo

 

-Burke

 

fr_rw = Rawandan French

 

On May 12, 2010, at 1:01 AM, Darius Jazayeri wrote:



He's talking about the rare case where you have:

 

en:Alpha, fr:Bravo

en:Xray, fr:Bravo

 

and then you are in locale=en and you search for "Bravo".

 

-Darius

 

On Tue, May 11, 2010 at 9:57 PM, Lu Zhuangwei <[hidden email]> wrote:

Burke:

Thanks for your reply. I got it, so as you said, name uniqueness is only applied within a locale. So once we find two encounterTypes have a same name in just one locale, then we will consider they are duplicate.

But, I can't understand this sentence "in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?" What dose it mean?


Lu



On Wed, May 12, 2010 at 9:36 AM, Burke Mamlin <[hidden email]> wrote:

So, name uniqueness is only applied within a locale; a match in the current locale always wins amongst other matches; and, in the rare case that there is more than one match but none in the current locale, then the result is undefined/random (i.e., whichever is found first)?

 

-Burke

 

 

On May 11, 2010, at 12:29 PM, Darius Jazayeri wrote:



I think there are several common use cases where we do want to return names that match in other locales:

* You haven't localized a particular type of metadata. (E.g. you did localize encounter types, but you didn't localize locations.)

* You haven't finished localizing a particular type of metadata. (E.g. someone just created a few new forms, and your bilingual administrator hasn't localized them yet.)

* You don't localize anything at all, but you still allow people to log into multiple locales so the webapp is translated for them.

 

Given that, I would prefer for LocationService.getLocation("Hopital de Cange") to get me back a result even if my authenticated locale is English.

 

If for some reason there's a type of metadata where the same string is the English name of one item, and the French name of another item, then you need to make sure to return the one whose name matches in the current locale first. (But I think this is a much less-frequent use case than the ones above.)

 

-Darius

On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]> wrote:

Getting an object by name across locales is okay iff the API applies
uniqueness across locales -- i.e., a name must be unique across all
non-voided names in all locales.

I worry that this could cause two problems:

(1) Isn't it likely some metadata names (e.g., for locations, encounter
types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
en_us perhaps)?

(2) If my name search matches metadata in a different locale, then I could
get search results that don't make sense to me, since the UI would be
rendering results in my locale that matched in a different locale.  This
case may be unlikely enough not to worry about.

Because of these two (reason #1 more than #2), I wonder if we'd be better
off limiting getObject(name) methods to the current locale
(Context.getLocale()).

-Burke


> Yes, HIV Intake and VIH Donnees de Base should return the encounter.  A
> helper method in HibernateUtil to do the criteria easily would be nice
> to have.
>
> A ticket is out there to prevent multiple names for metadata.
> http://dev.openmrs.org/ticket/872  This is an API level check, not a db
> constraint because we can have duplicate names for voided metadata but
> only one name for non-voided metadata.
>
> Ben
>
> On 05/11/2010 10:01 AM, Michael Seaton wrote:
>> Hi all,
>>
>> Lu brings up a good point below, which is - once we add localization to
>> the names of our BaseOpenmrsMetadata objects, how do we want Service
>> methods such as EncounterService.getEncounterType(String name) to
>> behave?
>>
>> My assumption is that we will want to check to see if any localized name
>> matches on each EncounterType. So, if we have:
>>
>> EncounterType:
>> id: 1
>> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>>
>> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>> EncounterService.getEncounterType(String name) in order to retrieve this
>> EncounterType, regardless of the user's current locale.
>>
>> Does anyone have another take on the expected behavior?
>>
>> As an additional note, it seems that we have no unique constraints on
>> our Metadata names. So, for example, it is possible for me to create 2
>> different Encounter Types with the same name using the administration
>> pages. Given this, how do we expect the getEncounterType(String name)
>> method to behave? Right now, my guess is that Hibernate is just
>> returning the first match found, but I'd think we would want our API to
>> be smarter than this...
>>
>> Thanks,
>> Mike
>>
>>
>> On 05/11/10 09:01, Lu Zhuangwei wrote:
>>> Hi, Mike
>>>
>>> When I am reading related codes for my project, I found that once I
>>> have modified "name" property of BaseOpenmrsMetadata to
>>> "localizedName", then I also need to modify those related methods in
>>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>>> column in *.hbm.xml files.
>>>
>>> Such as in method "getEncounterType(String name)" in
>>> "HibernateEncounterDAO":
>>>
>>> public EncounterType getEncounterType(String name) throws DAOException
>>> {
>>> Criteria crit =
>>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>>> crit.add(Expression.eq("retired", false));
>>> crit.add(Expression.eq("name", name));
>>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>>> }
>>>
>>> I think we should change the query logic in this method and now as the
>>> "localizedName" is of type LocalizedString, so I think we cann't only
>>> use such easy query manner like "Expression.eq(...)" any more.
>>>
>>> In this email, I just want to confirm that we need to resolve such a
>>> underlying problem, but how to resolve it, I think we can discuss in
>>> summer. Do you think so?
>>>
>>>
>>> Lu
>>>
>>> --

>>> Zhuangwei Lu(½ׯΰ)

>>> Mobile: +86 151-0103-7842
>>> MSN: [hidden email] <mailto:[hidden email]>

>>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)

>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



--
Zhuangwei Lu(陆庄伟)


Mobile: +86 151-0103-7842
MSN: [hidden email]

Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

Ben Wolfe Ben Wolfe
Reply | Threaded
Open this post in threaded view
|

Re: Retrieving openmrs metadata by name

Roger

We're referring to metadata like Encounter Types, Locations, Order
Types, etc in the system, not to Concepts at this point.
See this gsoc project: http://openmrs.org/wiki/Localization_Tools

A Concept's "Fully Specific" (aka primary) name will act like this, but
like you said, synonyms do not follow this same unique constraint.

Ben

On 05/12/2010 09:40 AM, Friedman, Roger (CDC/OID/NCHHSTP) (CTR) wrote:

> Burke, can we really guarantee this?  For example, if we have two
> diagnoses, "HIV Infection" and "AIDS", and usage in the locale is that
> AIDS is only a synonym for advanced HIV infection, reflected in the
> diagnosis plus the staging, we do get Darius' use case.  Likewise with
> TB, there are lots of ways to have extrapulmonary TB, only some will be
> named.
>
> *From:* [hidden email] [mailto:[hidden email]] *On Behalf Of *Burke Mamlin
> *Sent:* Wednesday, May 12, 2010 9:25 AM
> *To:* [hidden email]
> *Subject:* Re: [OPENMRS-DEV] Retrieving openmrs metadata by name
>
> Actually, not quite. Names should be unique within a locale, so there
> should never be a case where two of the same types of metadata have the
> name "Bravo" in the same (fr) locale.
>
> So,
>
> en:Alpha, fr:Bravo
>
> en:Xray, fr_rw:Bravo
>
> -Burke
>
> fr_rw = Rawandan French
>
> On May 12, 2010, at 1:01 AM, Darius Jazayeri wrote:
>
>
>
> He's talking about the rare case where you have:
>
> en:Alpha, fr:Bravo
>
> en:Xray, fr:Bravo
>
> and then you are in locale=en and you search for "Bravo".
>
> -Darius
>
> On Tue, May 11, 2010 at 9:57 PM, Lu Zhuangwei <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Burke:
>
> Thanks for your reply. I got it, so as you said, name uniqueness is only
> applied within a locale. So once we find two encounterTypes have a same
> name in just one locale, then we will consider they are duplicate.
>
> But, I can't understand this sentence "in the rare case that there is
> more than one match but none in the current locale, then the result is
> undefined/random (i.e., whichever is found first)?" What dose it mean?
>
>
> Lu
>
>
>
> On Wed, May 12, 2010 at 9:36 AM, Burke Mamlin <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> So, name uniqueness is only applied within a locale; a match in the
> current locale always wins amongst other matches; and, in the rare case
> that there is more than one match but none in the current locale, then
> the result is undefined/random (i.e., whichever is found first)?
>
> -Burke
>
> On May 11, 2010, at 12:29 PM, Darius Jazayeri wrote:
>
>
>
> I think there are several common use cases where we do want to return
> names that match in other locales:
>
> * You haven't localized a particular type of metadata. (E.g. you did
> localize encounter types, but you didn't localize locations.)
>
> * You haven't finished localizing a particular type of metadata. (E.g.
> someone just created a few new forms, and your bilingual administrator
> hasn't localized them yet.)
>
> * You don't localize anything at all, but you still allow people to log
> into multiple locales so the webapp is translated for them.
>
> Given that, I would prefer for LocationService.getLocation("Hopital de
> Cange") to get me back a result even if my authenticated locale is English.
>
> If for some reason there's a type of metadata where the same string is
> the English name of one item, and the French name of another item, then
> you need to make sure to return the one whose name matches in the
> current locale first. (But I think this is a much less-frequent use case
> than the ones above.)
>
> -Darius
>
> On Tue, May 11, 2010 at 9:02 AM, Burke Mamlin <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Getting an object by name across locales is okay iff the API applies
> uniqueness across locales -- i.e., a name must be unique across all
> non-voided names in all locales.
>
> I worry that this could cause two problems:
>
> (1) Isn't it likely some metadata names (e.g., for locations, encounter
> types, etc.) be identical across locales (e.g., fr and fr_rw, or en and
> en_us perhaps)?
>
> (2) If my name search matches metadata in a different locale, then I could
> get search results that don't make sense to me, since the UI would be
> rendering results in my locale that matched in a different locale. This
> case may be unlikely enough not to worry about.
>
> Because of these two (reason #1 more than #2), I wonder if we'd be better
> off limiting getObject(name) methods to the current locale
> (Context.getLocale()).
>
> -Burke
>
>
>  > Yes, HIV Intake and VIH Donnees de Base should return the encounter. A
>  > helper method in HibernateUtil to do the criteria easily would be nice
>  > to have.
>  >
>  > A ticket is out there to prevent multiple names for metadata.
>  > http://dev.openmrs.org/ticket/872 This is an API level check, not a db
>  > constraint because we can have duplicate names for voided metadata but
>  > only one name for non-voided metadata.
>  >
>  > Ben
>  >
>  > On 05/11/2010 10:01 AM, Michael Seaton wrote:
>  >> Hi all,
>  >>
>  >> Lu brings up a good point below, which is - once we add localization to
>  >> the names of our BaseOpenmrsMetadata objects, how do we want Service
>  >> methods such as EncounterService.getEncounterType(String name) to
>  >> behave?
>  >>
>  >> My assumption is that we will want to check to see if any localized name
>  >> matches on each EncounterType. So, if we have:
>  >>
>  >> EncounterType:
>  >> id: 1
>  >> names: {en="HIV Intake", fr="VIH Donnees de Base"}
>  >>
>  >> Then both "HIV Intake" or "VIH Donnees de Base" can be passed to
>  >> EncounterService.getEncounterType(String name) in order to retrieve this
>  >> EncounterType, regardless of the user's current locale.
>  >>
>  >> Does anyone have another take on the expected behavior?
>  >>
>  >> As an additional note, it seems that we have no unique constraints on
>  >> our Metadata names. So, for example, it is possible for me to create 2
>  >> different Encounter Types with the same name using the administration
>  >> pages. Given this, how do we expect the getEncounterType(String name)
>  >> method to behave? Right now, my guess is that Hibernate is just
>  >> returning the first match found, but I'd think we would want our API to
>  >> be smarter than this...
>  >>
>  >> Thanks,
>  >> Mike
>  >>
>  >>
>  >> On 05/11/10 09:01, Lu Zhuangwei wrote:
>  >>> Hi, Mike
>  >>>
>  >>> When I am reading related codes for my project, I found that once I
>  >>> have modified "name" property of BaseOpenmrsMetadata to
>  >>> "localizedName", then I also need to modify those related methods in
>  >>> Hibernate*DAO, except from I need to map "localizedName" to "name"
>  >>> column in *.hbm.xml files.
>  >>>
>  >>> Such as in method "getEncounterType(String name)" in
>  >>> "HibernateEncounterDAO":
>  >>>
>  >>> public EncounterType getEncounterType(String name) throws DAOException
>  >>> {
>  >>> Criteria crit =
>  >>> sessionFactory.getCurrentSession().createCriteria(EncounterType.class);
>  >>> crit.add(Expression.eq("retired", false));
>  >>> crit.add(Expression.eq("name", name));
>  >>> EncounterType encounterType = (EncounterType) crit.uniqueResult();
>  >>> }
>  >>>
>  >>> I think we should change the query logic in this method and now as the
>  >>> "localizedName" is of type LocalizedString, so I think we cann't only
>  >>> use such easy query manner like "Expression.eq(...)" any more.
>  >>>
>  >>> In this email, I just want to confirm that we need to resolve such a
>  >>> underlying problem, but how to resolve it, I think we can discuss in
>  >>> summer. Do you think so?
>  >>>
>  >>>
>  >>> Lu
>  >>>
>  >>> --
>
>  >>> Zhuangwei Lu(½ׯΰ)
>
>  >>> Mobile: +86 151-0103-7842
>  >>> MSN: [hidden email] <mailto:[hidden email]>
> <mailto:[hidden email] <mailto:[hidden email]>>
>
>  >>> Institute Of Software Chinese Academy Of Sciences(Öйú¿ÆѧԺÈí¼þÑо¿Ëù)
>
>  >> ------------------------------------------------------------------------
>  >> Click here to unsubscribe
>  >> <mailto:[hidden email]
> <mailto:[hidden email]>?body=SIGNOFF%20openmrs-devel-l> from
>  >> OpenMRS Developers' mailing list
>  >
>  > _________________________________________
>  >
>  > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>  > [hidden email] <mailto:[hidden email]> with
> "SIGNOFF openmrs-devel-l" in the body
>  > (not the subject) of your e-mail.
>  >
>  > [mailto:[hidden email]
> <mailto:[hidden email]>?body=SIGNOFF%20openmrs-devel-l]
>  >
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] <mailto:[hidden email]> with
> "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail.
>
> [mailto:[hidden email]
> <mailto:[hidden email]>?body=SIGNOFF%20openmrs-devel-l]
>
> ------------------------------------------------------------------------
>
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list
>
> ------------------------------------------------------------------------
>
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list
>
>
>
> --
> Zhuangwei Lu(陆庄伟)
>
>
> Mobile: +86 151-0103-7842
> MSN: [hidden email] <mailto:[hidden email]>
>
> Institute Of Software Chinese Academy Of Sciences(中国科学院软件研究所)
>
> ------------------------------------------------------------------------
>
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list
>
> ------------------------------------------------------------------------
>
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list
>
> ------------------------------------------------------------------------
>
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]