0

Some prerequisites on the remote process:

q)\p 15222
q)t:([id:10 20 30]data:`aa`bb`cc);
q)kt:([]id:`t$10 20 20 30 30 30; num:til 6);

and the following will be performed on a local process:

  1. The size of kt looks the same from both sides:
q)-22!`::15222 "kt"
138
q)`::15222 "-22!kt"
138
  1. But meta's are different:
q)`::15222 "meta kt"
c  | t f a
---| -----
id | j t
num| j
q)meta `::15222 "kt"
c  | t f a
---| -----
id | j
num| j

Why is it so? - why the transferred table does not contain a whole information as its source (despite of the sizes are the same)?

I suspect this somehow related to enums - q completely removes enum info - is it true?:

// remote
q)e:`a`b`c;
q)e1:`e$`b`a`c`c`a`b;
// local
q)`::15222 "type e1"
20h
q)type `::15222 "e1"
11h
egor7
  • 4,678
  • 7
  • 31
  • 55

2 Answers2

1

Yes, enums (and thus foreign keys) aren't preserved when transported over IPC to another process.

Equal length from -22! doesn't mean identical content.

terrylynch
  • 11,844
  • 13
  • 21
1

The reason for the difference between the two tables is because the enumeration domain isn't being sent over IPC so there is no guarantee that the enumeration domain exists in the local process or is the same as the remote process. If it were to send over the enumeration domain from the remote process then there's also the risk that it may overwrite a local enum domain in the local process. Another point to note is that -22! checks the serialised size which will remove any foreign key on both client and server. It might be worth checking out https://www.aquaq.co.uk/q/adventure-in-retrieving-memory-size-of-kdb-object/ for further reading on determining memory usage of kdb objects.

Robert Coen
  • 11
  • 1