i have problem with full text search in innoDB/XtraDB engine.
i have full text on a column, some value is 1 or 2 length for example 'a' or 'aa'.
i set ft_min_word_Len=1 and show variable show me that this variable set to 1. but when i query like this i get no result :
SELECT * FROM test.t1 t where match(text) against('aa' );
but when i change table engine to aria or myisam i get result.
what is the problem ?
i want to use innodb/Xtradb , not aria.
please help me.
You should change innodb_ft_min_token_size to 1. The setting ft_min_word_Len refers to myisam tables. See "Excluded Results" section on this page of the mariaDB knowledge base site.
Also see this review of the innodb full text search feature:
...I was a bit surprised to see that the default minimum word length was less than the value of ft_min_word_len. Those legacy ft_% variables continue to apply only to MyISAM fulltext indexes, evidently. There's a new bundle of system variables to control InnoDB Fulltext...
Related
I have 2 controls, Start Date and End Date. I would like to have the min and max of a particular field to be selected as default values of the controls. Is there anyway to do it. I tried creating a calculated field, max or min({field},[],pre_filter) but later realized that we can't add calculated field into a parameter. I'm using Standard Edition. Any help/idea is much appreciated.
I encountered a similar question recently and developed a workaround for this by connecting to my Redshift cluster which required 2 things:
A table housing all users for the dashboard in question
A table that houses the metrics I'm setting defaults on
I created a separate dataset for setting default parameters which contained a complete list of my users, along with the min/max values from querying the second table with the value. Something like:
SELECT USER_NAME
, MIN_METRIC
, MAX_METRIC
FROM USERS A
CROSS JOIN (SELECT MIN(METRIC_VALUE) MIN_METRIC
, MAX(METRIC_VALUE) MAX_METRIC
FROM METRIC_TABLE) B
Once you've built this new data set, you'd add it to your existing analysis and utilize it for setting default parameters, adding the controls, and setting the filters to key off of them.
The downside to this approach is that it does require an exhaustive user list as any null users would see whatever the non-dynamic defaults are, but with an appropriate user table, this shouldn't be an issue.
I'm testing Kibana 4 for a project.
I have created an index from my database table which is composed by 3 fields:
Date
User
Action
I would like to display my index as a simple table (3 column, N rows) in my dashboard.
I tried to use "Data table" visualization but I can't find a way to display my results without any Metrics (Count, Sum etc...)
Maybe is pretty simple and I missed something... is there a way to do this?
Regards,
On the Discover tab, create a view that has just the fields you want and then save that as a search.
On the Dashboard tab, click on Edit then hit the + Create new button to add a widget, but if you look at the top, there's a Searches tab. Select that and add your saved search in.
[Elastic 7.x / 2019 Update]
I was a bit confused when I read #Alcanzar's answer so I am sharing a little more noob-friendly step-by-step how-to here :
STEP 1 : Create the Index Pattern
STEP 2 : Go to the Dashboard view, and create a view on your index
Select each column you want to include/add in your view by clicking "add" on it (The confusing part is that until you do that, you will have a "scrambled" view listing everything in a jumbled way.)
STEP 3 : Go to the Dashboard view, and create a view on your index
The trick is to select the specific columns you want to include... and voila !
Don't forget to save your view, this will help a lot in the process.
In Kibana 7.5.0 you can do it as follows:
Go to Discover section
Select fields you are interested in
Click on Save to save your discover search so you can use it in visualizations and dashboards
Click on Dashboard and create a new dashboard
Click on Add and select the panel
There is no step 6
The accepted solution has its pros (if, for simplicity, you see your index as a table, this is the only way to deal with rows naturally) but also cons (it allows the user to see too much information, by expanding the records that appear in the table; users cannot get an export of the values).
So if you plan to build tables to use in reports seen by users which should not see everthing and may want to get exports of the data, I recommend a different (hacky) approach using Table visualizations:
Say you have three columns A, B and C:
If there are no duplicates considering the combined values of A and B, you can use these two vales as aggregation fields, and then set a Max or Top hit Metric for C.
If even A, B and C have duplicates, then you can use the three of them as aggregation fields and add a Metric count, that will give you the number of repeated rows. This solution makes somehow sense, because instead of repeating the same row 'n' times you just tells you should have repeated 'n' times that row.
If A and B have duplicates but A, B and C are unique, then there is, afaik, no elegant solution. You have to use the three of them as aggregation fields, but then you would have a dummy metric at the end (e.g. count, always equal to 1).
Why? why do we have to go through all of this? that is another question...
I'm testing Kibana 4 for a project.
I have created an index from my database table which is composed by 3 fields:
Date
User
Action
I would like to display my index as a simple table (3 column, N rows) in my dashboard.
I tried to use "Data table" visualization but I can't find a way to display my results without any Metrics (Count, Sum etc...)
Maybe is pretty simple and I missed something... is there a way to do this?
Regards,
On the Discover tab, create a view that has just the fields you want and then save that as a search.
On the Dashboard tab, click on Edit then hit the + Create new button to add a widget, but if you look at the top, there's a Searches tab. Select that and add your saved search in.
[Elastic 7.x / 2019 Update]
I was a bit confused when I read #Alcanzar's answer so I am sharing a little more noob-friendly step-by-step how-to here :
STEP 1 : Create the Index Pattern
STEP 2 : Go to the Dashboard view, and create a view on your index
Select each column you want to include/add in your view by clicking "add" on it (The confusing part is that until you do that, you will have a "scrambled" view listing everything in a jumbled way.)
STEP 3 : Go to the Dashboard view, and create a view on your index
The trick is to select the specific columns you want to include... and voila !
Don't forget to save your view, this will help a lot in the process.
In Kibana 7.5.0 you can do it as follows:
Go to Discover section
Select fields you are interested in
Click on Save to save your discover search so you can use it in visualizations and dashboards
Click on Dashboard and create a new dashboard
Click on Add and select the panel
There is no step 6
The accepted solution has its pros (if, for simplicity, you see your index as a table, this is the only way to deal with rows naturally) but also cons (it allows the user to see too much information, by expanding the records that appear in the table; users cannot get an export of the values).
So if you plan to build tables to use in reports seen by users which should not see everthing and may want to get exports of the data, I recommend a different (hacky) approach using Table visualizations:
Say you have three columns A, B and C:
If there are no duplicates considering the combined values of A and B, you can use these two vales as aggregation fields, and then set a Max or Top hit Metric for C.
If even A, B and C have duplicates, then you can use the three of them as aggregation fields and add a Metric count, that will give you the number of repeated rows. This solution makes somehow sense, because instead of repeating the same row 'n' times you just tells you should have repeated 'n' times that row.
If A and B have duplicates but A, B and C are unique, then there is, afaik, no elegant solution. You have to use the three of them as aggregation fields, but then you would have a dummy metric at the end (e.g. count, always equal to 1).
Why? why do we have to go through all of this? that is another question...
How to remove invalid Null values that are not present in database but showing in prompts in OBIEE. For some of the columns Null Values is valid but for other it is not. So i want to display null value in prompt only if it is valid.
you will have to got to rpd and modify the column in physical layer; mark it Not Nullable (uncheck the Nullable check-box)
Seven years later... is this still useful?
Anyway, I've found out that there is a better solution if you want to avoid using a Choice List wih the "SQL Result" option and stick to the "All Column Values" option (because this one allows you to use the "Limit Values by" option, which I need).
There is a parameter in the instanceconfig.xml file that defines this behavior: "ShowNullValueWhenColumnIsNullable" (wrongly documented in some versions as "ShowNullValueInPromptsWhenDatabaseColumnIsNullable", as per this Support Doc)
You can see its usage in the Fusion Middleware System Administrator's Guide (search of one of the two property names above).
If you have a limited number of possible values, you could chose Specific column Values under Options in the edit prompt dialog box.
Also, checking the box to require user input will sometimes resolve this null value problem, however this is not always the case nor is it always possible depending on your situation.
Additionally, go to Edit Dashboard Prompt, in Choice List Values drop-down list select SQL Results, then write the SQL statements as columnname is not equals to “Unspecfied” (In this way we can remove Null’s also).
Finally, you could go to the Physical Column properties in Physical Layer and Disable the Nullable option by unchecking the box.
I prefer to work in my filter in the where statement (is not null or not like '').
Another situation you might notice is an extra blank row in the filter. This can be removed by setting the preferences is required in the prompt filter.
Good luck.
When I try to search products by SKU, I get incomplete results. For example: I have products with SKU IR-CP-CH_1 and A-453-B-I_1. Both products are configurable products, both are visible for Catalog, Search. I get correct result for query IR-CP-CH_1 and no result for A-453-B-I_1.
Indexes are rebuilt. I use combined search type (like + fulltext). In advanced search everything works fine.
I suggest you take a quick look in your database at the table catalogsearch_fulltext. In the data_index column you should be able to see the SKUs as part of the full text string Magento creates for quick searching in.
See if you can either manually spot the elusive SKU 'A-453-B-I_1' or hit it with an
SELECT * FROM catalogsearch_fulltext WHERE data_index LIKE '%453%'
Maybe the SKU got entered with some strange characters or a space instead of a hyphen. You could search in the product_id column instead to see what search string Magento does have for that SKU.
If the string is in the table and the character glyphs match exactly, then I think you are looking to indexing, caching, stock, store views etc as suggested in the comments above by others
If the string is not in the table at all then I think you are looking to 'visibility'.
If you look in the table catalogsearch_query and find your search string 'A-453-B-I_1' then look to the num_results column - if that value is greater than zero then items were found but it's not displaying that product for some reason.
**EDIT following comments below
Actually I think you should remove that '0' result from the catalogsearch_query table. You could remove it using SQL or phpmyadmin. Magento will return a result from catalogsearch_query if it finds one rather that search catalogsearch_fulltext every time.
It is possible that at some point the result was '0' but now it is non-zero but Magento is stuck with the '0 results' in the catalogsearch_query table.
There is more analysis that can be done, but try that first and if it still isn't right we can look at trapping the database query to try to understand why Magento thinks the result is zero.
For information, in my case, a free module (activo_catalogsearch) was breaking the research by sku because it was not up to date and probably conflicting with magento 1.9.4.1 (worked fine before with magento 1.9.2.1)