Publication API - global search

pricua

Hi,

we would like to use the global_search API functionality to develop a new website that displays Dedalo information.

The API test page indicates that a special server configuration is required to use this functionality.

We have been looking through the documentation but have not found where it indicates what this special configuration should be.

Could you please tell us how we have to configure the server for it to work?

At the moment what we have done is that in some diffusion tables we have added a last field of type field_mediumtext and name global_search, with the merge_columns property with the fields to include in the global_search, similar to the tch333 field, but when using global_search the server returns the error 'Base table or view not found: 1146 The table 'xxx.global_search' does not exist'

I imagine that we need to add or configure something that we do not know.

Alex

Yes, global search is an experimental function and is not documented. I try to explain it.

Global search has two different approaches:

by table:
as tch333 does, get the data in other fields and join into a property that you can use in /records API calls directly in the same way as other properties/columns.
This way don't use the /global_search API calls. It is used and work properly and you can implement and use safely.
by database:
It's an experimental feature and the definition is not finished. You can try it, but it could be changed in the future and maybe we remove the /global_search API call and use only /records call... so answering to your question. How it works?
1 define a table into the hierarchy as global_serach, and add all columns that you want to use.

2 Think that which columns you will need and they nee to be compatible with different columns in other tables, for example if you define a date column in global table you can send dates for other tables to it, but, maybe, you will need to send only date in but not date out because the search will be only for date in and also is possible send other kind of data as location and maybe is not useful in the query.
Note: The properties of the global_search table in the ontology do not point to any specific ontology component:

3 When you have your global search table you can define a map in the source table to point the columns into the global search table. see the properties of v5 in mdcat495. Do not use the map of global_search_map is totally deprecated and will delete into the schema, the correct (but unfinished) is global_table_maps it defines the source_columns and target_columns and how the data need to be joined.
4 When you have the definition you can use it by /records directly (and maybe is the best option), OR
5 you can define specific columns as: list_data, link, and full_data in your global_search table to use the API /global_search.
/global_search calls will use the full_data to do the query and return the list_data to show information and link to point the row to source table.

I hope that's clear... and remember that the /global_seach API call might disappear in the future...

Best

pricua

Hello,

Thanks for the reply. It is perfectly explained and very clear.

Knowing this, we are going to use the first option, using the global search by table.
It seems easier to configure and we can make sure that it will always work, in case at some point it is decided to eliminate global_serach API option.

Best