Send Feedback
Skip to content

Serializing a table as an object

The simplest way to serialize a table is as a single object.

Any q object can be saved to disk, but when we do that with a table, we often call that a flat table to differentiate it from other types of serialization. There are multiple ways we can do this.

save and load

Keywords save and load let us serialize and write any q object to a file of the same name in the working directory. That includes tables, making this the simplest way to persist one.

q)cities:([]city:`Tokyo`Delhi`Shanghai;pop:37435191 29399141 26317104)

q)key `:.                       / nothing in working directory
`symbol$()
q)save `cities
`:cities
q)key `:.                       / file in working directory
,`cities

q)delete cities from `.         / delete from memory
`.
q)cities
'cities
  [0]  cities
       ^

q)load `cities                  / load from filesystem
`cities
q)cities
city     pop
-----------------
Tokyo    37435191
Delhi    29399141
Shanghai 26317104

Tip

By specifying the extension (for example .csv, .xls) we can also export the table in another format.

q)save `cities.csv
`:cities.csv
q)read0 `:cities.csv
"city,pop"
"Tokyo,37435191"
"Delhi,29399141"
"Shanghai,26317104"

While this is satisfactory for many needs, it lacks further customizable features. For more options for writing and reading we need the keywords used to define save and load.

set and get

Keywords set and get differ from save and load:

  • set is a binary; its left argument says where in the filesystem to write
  • get returns the table value rather than the name of the variable it has been assigned to

Notice the similarity of reading a value from memory to reading it from the filesystem.

q)get `:cities                      / from filesystem
Tokyo   | 37435191
Delhi   | 29399141
Shanghai| 26317104

q)get `cities                       / from memory
city     pop
-----------------
Tokyo    37435191
Delhi    29399141
Shanghai 26317104

q)`:foo/bar/bigcities set cities
`:foo/bar/bigcities
q)get `:foo/bar/bigcities
city     pop
-----------------
Tokyo    37435191
Delhi    29399141
Shanghai 26317104

Use cases

Serialization as a flat table suits a table that is

  • small relative to memory
  • frequently read
  • has most of its columns required by most queries

Splayed tables
Partitioned tables
Segmented databases