[Koha-devel] New KOHA3 API -design issue

[Paul POULAIN]

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)