Open Source Document Management System | OpenKM

Hi,

I got a problem.

Assume the following property group:
I added this property to a document. Ok. Now I go to Search - Advanced and add this property and than hit "search". But I got no results.

First think I thought of, was the DbSearchModule.java:336. There you convert the property group value to lowercase. But I really need mixed case! So I replaced this line with: But I still getting no results, but now the queryString looks good. Do you have any idea, whats going wrong here? I'm using the latest sources of the community edition shared on sourceforge.

Thanks a lot.

I found another hint.

It seems to be a problem with camelCase. If I only use lower case characters, everything is working.

While in OpenKM code everything is fine. But in SearchDAO.java:233 you're going into hibernate code.

1. org.hibernate.search.query.hibernate.impl.FullTextSessionImpl.class
2. org.hibernate.search.query.hibernate.impl.FullTextQueryImpl.class

There something happens (I got no source code to debug here), and than the SearchDAO receives the query result.
So it seems, hibernate got some problems with camelCase.

Do you have an idea what this problem could be?

Thanks.

Edit: I found another interessting hint. If I remove toLowerCase() from ...mixed case isn't working anymore. But if I use toLowerCase...mixed cases are working? Hm???????

I suggest do not use strange characters for your value "pc.test.Select.Id1" do as "pcTextSlectId1" ( better without white spaces, points, - etc... ) os use number like 001, 002 etcc ( normalized in length ), that will also be a good practice.

Ok, I found a reproducable case.
There, I can search for Option B but not for Option A. The only difference is the first uppercase character of Optiona. When I change property group to "optiona" instead of "Optiona", everything is working.

But when I remove the toLowerCase() of valueTrimmed, nothing is found anymore.

I don't know whats happening in hibernate behind. But do you have any idea how I may be able to use mixed case option values in selects? I really need something like "optionA" is different than "optiona". The databases behind (tested with Postgres, MySQL and internal) differentiates between lower and upper case characters. So inside the database, I can use "optionA" and "optiona".

Why are you using databaes query and not openkm search engine ( lucene available from openkm API ? ). My suggestion is take value as primary key value you'll use in database ( do not use strange characters etc... ) good practice are lowercase text or better convert to 001, 002 -> 999 values ( that sure will go right too ), if you're doing some application in source code you can map 001 value to a string contant-

I'm still using the okm search engine (findPaginated) with a specific property group map to find. THAT is the problem, because the resulting query generated by openkm only contains lowercase property groud property ids. So, if I have a property id with an upper case, I'm not able to find it through openkm search engine. But for me it is really important if a property id is "id" or "ID", because on a later state I need this knowledge to map this id into another datebase for additional metadata etc.

So I'm only wondering, why you do "String valueTrimmed = ent.getValue().trim().toLowerCase();" - for some reason?

For what I understood internally we're are optimizing query values to lower case. Well that can be done for several reason, the first is that has not much sense do primary keys in lower and upper case. For example imagine you're tagging files with keywords, and somebody wrote "House" and other wrote "house" these terms are exactly the same. We've founded in the past some problems on users what are using uppercase and lowercase in this scenarios and that could be the reason why we've decided apply some optimization internally to force all in lowercase ( for what you told us, this is causing a problem to you ).

In my opinion, the problem is not upper case or lower case, the problem from my point of view is that you're doing bad use of primary keys. My suggestions what covers openkm optimization and your needs is mapping your wished primary keywords values, for example:
your_value okm_internal_value
optiona 001
Optionb 002

And simply you need a method to translate your values to openkm and vicevera. ( From openkm UI only are show descriptions, then your problem must be in some kind of remote integration )

Ok, thanks for the information. I will think about some kind of mapping mechanismen. It's a bit sad, because I hoped to find a solution for using mixed case primary keys. The database system below (MySQL, PostgreSQL, ...) all allow mixed keys (like 'Keya' is not the same as 'keya'). But it seems hibernate absorbs mixed primary keys in some way.