gyorokpeter-kx
Forum Replies Created
-
It’s a property of some operations and not others. exec just picks the column out of the table without walking through it. The equivalent operation is tab[;`col1]. However tab[`col1] is an odd operation because normally the first index to a table is the row and not the column, which implies that q must do something extra under the hood to come up with the same result as tab[;`col1], which includes rebuilding the column.
Similarly if you include a trivial condition in the exec such as exec col1 from tab where 1b then it acts the same as just exec col1 from tab . However if you add a nontrivial condition, even if it’s always true, such as exec col1 from tab where 0<=i then suddenly q has to walk through the column to build the answer which means it will be collapsed. Try different operations with t to see the difference in the time they take (I tried with 10000 rows and t:1000 to get a measurable result).
-
q collapses dictionaries with matching keys into a table. However this doesn’t happen if the list in question is a table column.
The pretty printing logic still does the conversion as part of printing the value, but doesn’t change the underlying type, which means functions that expect a “real” table will fail.
You can force the collapsing by remaking the list using an each:
q)type(::)each exec col1 from tab 98h q)cols(::)each exec col1 from tab `col11`col12
-
tab.col1 is another equivalent to tab[;`col1] (besides the limitations that it can’t be used everywhere). It’s tab`col1 that is the odd one out since it breaks the usual rules for indexing.
-
How did you create the table? Did you load it from a CSV or similar file? You might want to open it in a hex editor because you might have invisible special characters in there. The clue is that the vertical bar on the line of TRADE_DT is further to the left than for the other columns – q takes the length of the column name in bytes to find where to draw that line, and if there are invisible characters, those will shorten the actually printed width of the name, resulting in the line appearing to the left. The same occurs if you have a UTF-8 input file where some characters are represented by a different number of bytes than the number of character slots they take up on the screen. However such characters are not recommended for use in column names because then you can’t use a select query.
As a quick fix you could use .Q.id on the table which will transform all column names into valid identifiers by removing all invalid characters. However if the source file is used by other applications, they could also run into a similar issue so it might be worth investigating if there is anything wrong with it.
-
Have you tried installing libsnappy?
File compression | Database | kdb+ and q documentation – Kdb+ and q documentation (kx.com)
-
From the usage perspective it’s almost the same, the only difference is that the paths should start with ms:// and you need to use different environment variables.
-
It would be helpful to see all the relevant logs including those of RC, DAPs and aggregator.
-
Can you please paste in the query you are executing and any relevant logs?
What is the size of the data? If your query is trying to fetch too much data, it may result in processes hitting the memory limit and crashing, resulting in the query timing out.
-
Can you please paste in the error message? My guess is it could be related to entitlements.
-
Although this is not spelled out exactly in the exercise, it is expecting you to use the output of exercise 7. So if you run the test for exercise 7 and it passes, then use viewtab in exercise 8, it should have the correct number of rows.
What is your number of rows in viewtab before and after exercise 7, and what is the number of rows in sortedViews?
-
The test checks for an exact match with the expected table, not just the schema. Can you check if you created the optRef table correctly? How many rows are there in the table?
-
The update statement normally returns the modified table. If you want to save the result back to the in-memory table, you have two options:
- use an assignment statement to overwrite the table with the result
- pass the name of the table to update rather than its value
The second option is explained at QSQL query templates | Basics | kdb+ and q documentation – Kdb+ and q documentation (kx.com).
-
Apparently the exercise 1 test doesn’t really check the table, only that it exists.
According to the description, getOptionRef takes a list of IDs, but you are passing in a symbol, and due to some bad luck this doesn’t result in a type error but the function returns all the rows matching your symbol which there are none.
-
The question is asking you to save your SQL code to variable ex1. What you are doing instead is executing the query and putting the result into ex1. This is why the second check passes (since the CREATE TABLE was executed) but the first one fails (because the variable doesn’t contain the SQL command).