Login or Join the Community (free)[You only need to join if you want to post to our forums or subscribe or donate.]
Thanks to our sponsors: 
OpenVPMS is developed with the help of various tools including the Java profiler 
Thanks to our sponsors:
OpenVPMS is developed with the help of various tools including the Java profiler
Re: Wildcard Search as Default
By default, all searches are effectively a "starts-with" search i.e. whatever text you enter gets changed to "term*" (or 'like "term%"' in SQL) before the search is issued. The advantage of these searches is that the database can locate matches quickly using column indexes.
A "contains" search, "*term* (or 'like "%term%"' in SQL), cannot use column indexes to the same extent, as the term can appear anywhere in the record. At worst, the database may have to scan every record to locate matches. On a large database, this could be an extremely slow operation.
As such, I don't think "contains" should be the default search.
-Tim
Re: Wildcard Search as Default
Hmmm...
I guess thinking about it more, the times I would like wildcard searches to be the default are not when searching clients or patients (where I imagine the speed issues might be a problem).
More when searching lookups (macros in particular) template names (letters, reports, forms). Would this be a more reasonable request?
Example:
- When writing discharge letters we create new letters (would be nice to have wildcard search here).
- We then insert macros into our letter text input box (would be super nice to have wildcard search here as we have a lot of different discharges. For example I have ones for vomiting, vomiting + diarrhoea, diarrhoea, cat vomiting.... these are much easier to narrow down with wildcard searches).
Re: Wildcard Search as Default
The issue then becomes how to do a 'starts-with' search if the default is 'contains'.
There could be an dropdown option that selects the type of search to run i.e. 'starts-with', 'contains', 'ends-with', and this could default to 'starts-with' or 'contains' depending on the archetype (customer, macro etc).
Personally, I think just adding wildcards manually as required is simpler.
Re: Wildcard Search as Default
I think that this is also one of those areas where naming convention is important, ie one wants to use a 'most significant part first' convention, ie "socks, size 11, brown" rather than "brown size 11 socks".
In our case where we have forms & letters that are practice location specific, all those for location CC have CC at the start of the name, ie "CC Post Surgery - Castration" so 'cc' pulls all the CC forms & letters and 'cc post' pulls all the post operative ones.
For macros, the search in the Alt-M screen (as it says in http://www.openvpms.org/documentation/csh/1.7/concepts/macros ) ".. searches both the code of the macros and their names. Hence entering say 'dg' will find all macros with code starting 'dg' and all macros whose name starts 'dg'."
Hence you can have a set of dsr (discharge reason) macros and search through them either by using their codes (ie search on 'dsr') or their names.
Finally, it is also useful to remember that one can sort the select screen on various columns - eg you can sort the macro select screen by code, name or description and this thus gives the possibility of using different ordering conventions for the name and description - eg "socks, size 11, brown" for names and "brown size 11 socks" for description.
Finally finally - the overhead in adding a % at the start of the string will probably be less than selecting a search type.
My vote - stay as is.
Regards, Tim G
Re: Wildcard Search as Default
Hi,
I guess it comes from being used to Spotlight and Google searches where they search the entire string. Also from watching staff members scroll through pages of macros looking for the correct macro/letter because they forget they can search DischargeTERM or %TERM.
Regardless of if I change my macros to Dg (they all start with DischargeXXX at the moment) which is a large amount of work as I have to do each individually, staff will still need to scroll through multiple pages looking for the correct macro (we have a few and try to add new ones as time goes on). Their other alternatives are to remember all discharges start with Dg (possible but more stuff for staff to remember and non friendly to staff who are less computer literate and struggle to remember how to do things on the computers already) or do a wildcard search (ditto - I have explained this concept to staff several times and some catch on and some just never will).
To use my example of why I still think full wildcard seach is better.
I have 5 macros (DgVomit(in patient); DgVomit+Diarrhoea; DgVomit(Cat); DgVomit(out patient); DgDiarrhoea). I search DgVomit and will get what I want (though it would be easier to just serach "Vomit". However if I go to Search DgDiarrhea I will miss at least one entry I want. So I always have to search %Diarrhoea if I want to get both my Diarrhoea entries. It also makes creating new macros and the such easier because as long as the name contains the term it will be captured in the search - naming conventions are not so important any more. This is even more important because I might think "vomiting" but another vet might think "gastritis" for the same thing and so unless they remember we have called that discharge DgVomit will be looking for DgGastro... Wildcard search default I call it Discharge Vomit (Gastritis) and happy days - everyone finds what they are looking for.
Another example. I have different discharge macros for ratbait intoxications. Except I can never remember if I have called it ratbait; rat-bait; rodenticide intoxication; anticoagulant rodenticide intoxication etc. I basically have to do a wildcard search to find these or do the scroll... If I wildcard search I can put all those terms in the name and find them. If wildcard is default it becomes even easier.
If %TERM% is default it should always capture any of the TERM% entries so there shouldn't need to be a selection for this. You will always get these results anyway, it will now just also capture others that previously it would have missed.
Anyway, might be one where we agree to disagree +/- effort of implementation not worth the potential payoff!
Cheers,
Adrian
Re: Wildcard Search as Default
Adrian - upon reflection, I admit to coming around to your view. If we look at the macros ONLY, then we have the following considerations:
Consequently - I am happy to cast my vote with you and agree that adjusting the macro search to use %XXX% rather than XXX% is not a stupid machine hogging idea. It will provide a more human friendly macro search facility with v.small performance overhead [because of the number of macros and the number of times that macro search is used].
If Tim A is worried about the 'should not force a change on users' aspects, then the obvious thing to do is to add a practice level switch "substring search for macros" to control whether to use "%XXX%" or "XXX%".
Regards, Tim G
Re: Wildcard Search as Default
comment deleted
Re: Wildcard Search as Default
Hi,
Coming back to this thread... the change made to the macros search seems has been well received. It has made searching for macros much easier.
Question - Can we get this extended to products as well. As with the discussion above. Performance hit I imagine shouldn't be too high (don't have vast numbers of products) and it would make searching for products much easier. I imaging there might be some differing opinions on this so perhaps this is one where there should be a practice level option to turn it off and on...?
Thanks,
Adrian
Re: Wildcard Search as Default
Oh, and on further reflection...
- Suppliers (referring vets and just general supplier search)
- All the searches in the admin section... :)
Re: Wildcard Search as Default
I'm for it. I agree that it makes life alot easier. Maybe it should be switched on/off at the user level?
Re: Wildcard Search as Default
Until there is support for User Preferences, I think this will need to be supported via configuration files (i.e. QueryFactory.properties). Each archetype can have its own query implementation, so it is a matter of identifying which archetypes need substring search support. So far there is:
Substring search would be enabled by adding a substring=true configuration option. E.g:
It would default to false if not specified.
Re: Wildcard Search as Default
OK, we will fund at least 1/3 of the user preferences project and will look for others to get this project going. The time we will save in simply having the home screen default to the worklist for the vets will make this worthwhile for us.
Otherwise it would be good to have wildcard search for all those listed.
Re: Wildcard Search as Default
We'd (Sam) would be happy to fund 1/3.
Greta
Re: Wildcard Search as Default
See http://www.openvpms.org/project/wildcard-searches
Note that this project doesn't rely on the User Preferences project; configuration is via the existing QueryFactory.properties file which will be pre-configured to use substring searches for those archetypes listed.