If there’s the possibility of returning multiple order types by class name (i.e., if we’re not enforcing a business rule that says that there’s only one order type for each class name), then this would be correctly implemented as:
public List<OrderType> getOrderTypesByClassName(String javaClassName) {
return sessionFactory.getCurrentSession().createQuery("from OrderType o where o.javaClassName = :javaClassName", OrderType.class)
.setString("javaClassName", javaClassName).list();
}
That’s the up-shot of @dkayiwa’s comment. That does make things potentially more complex, but that’s the nature of the data model.
The alternative is to make the PR add a unique constraint to the order_type.java_class_name field, after we confirm with the community that that is indeed the expected behaviour and no one is relying on having multiple order types serviced by the same Java class. Then we can reliably use:
public OrderType getOrderTypeByClassName(String javaClassName) {
return sessionFactory.getCurrentSession().createQuery("from OrderType o where o.javaClassName = :javaClassName", OrderType.class)
.setString("javaClassName", javaClassName).uniqueResult();
}
Although we might need to fix some test data to reflect this data model change.
In general, though, instead of querying the database by javaClassName, it’s like better to just ensure we are using something like DrugOrder.class.isAssignableFrom(object), kind of like we already do in OrderService.
@ibacher agreed. #1 is what we need I believe (in our Rwanda distro we have multiple Order Types for org.openmrs.DrugOrder). See my comments on the ticket and let me know what you think:
@mseaton@ibacher for the Record, our standardTestDataset.xml has more OrderTypes other than DrugOrder , and TestOrder
so just like @dkayiwa suggested , limiting the ResultSet to 1 is wrong business-wise
What would be the case if someone or some other Distro needed an OrderType say for X-Ray or Lab ? Won’t that wrongfully call for some other refactoring. Should we for now keep the scope around DrugOrder and TestOrder
I refactored the method to return a list instead , but this caused breaks elsewhere .
OrderService@Authorized(PrivilegeConstants.GET_ORDER_TYPES)
public List getOrderTypesByClassName(String className);
**OrderServiceImpl**
In this case, wouldn’t the more appropriate name for the first method be
public OrderType getRandomOrderTypeByClassName(String ordeType){}
What would the definition of the method returning a single order type when there are multiple types for the class? How do you know which one you will get?
Ha ha good one .@burke I have no objection for that because the pool is actually bigger than i had initially anticipated . so yes it could makes more sense . Though @mseaton is having the idea that we have a method which returns any of these two conditions
A list of similar OrderTypes or a List of different OrderTypes , none to limit the size.
Neither of these should need us to return just a single Order type per classname. … So I’d change your service method to return a List rather than a single Order Type.
What he’s suggesting is that, e.g., here and here if getOrderTypesByClassName() returns more than one result, we throw an exception notifying the user that the must explicitly set an order type.
I would also change things here so that instead of loading the order type by class name, we just check something like: