Tümer Garip a écrit :
Hi Paul,
As I work more on this issue of ZEBRA API more problems arise and thats why I have written this document. To have more details in biblio and items tables i also think is not an issue of CPU or disk space. Both approach is still acceptable. I kept the barcode as well as you noticed. My idea is that we mainly use ZEBRA for searching but use SQL to reach a record with unique indexes. This way we can do some load balancing and let zebra do the heavy work. SQL is as fast when reaching unique records.
Currently I have a bigger problem that our current zebra design does not allow merged resultsets. I am working heavily on this to see what can be done without too much CPU overhead. i.e. Currently I cannot search a title in a specific library branch.
the problem is a consequence to the splitting of items & biblios in 2 different zebra DB isn't it ? However, thx, it's much much much more clear to me. and i'm ++ FOR this solution. The need for some semantically easy to understand datas in SQL is stats & debugging & ... purposes. So I think we need only a few values in biblio tables. Something like title/author/itemtype. All other values could be "moved to" koha_attr new table.
The second functionality is that i can now create as many virtual fields as i want on the fly. As you may have noticed I have conference_name defined. So if I index my zebra with conference_name as long as define it in my koha_attr it will appear as a searchable field in my search screens. All these field names do not have to be mapped to marc_subfield_structures but if you want to use them in your templates as <!--TMPL VAR NAME="conference_name"--> than you have to map tham to your MARC tables ofcourse.
except that any virtual field would have to be added to zebra config file as well, needing a reindexing ? or am I missing something ?
And lastly it says whether you sorted on that field or not. If you did then it gets included in your sort dropdown menus. No hardcoding. You may decide to sort on a field that you do not think you needed now. When you do just set the flag sorts to true and your Search page will have it included.
iiuc, the advanced search feature could also take benefits of this koha_attr table : the library could define which "fields" they want to have in the list. That's exactly something requested yesterday !!! (in koha_attr, we could have a "field for opac" checkbox : if unchecked, the search is only for librarians, otherwise, it's for both interfaces)
I hope this explains it better and I await your comments on this.
you've got them, read you later. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)