Handle data for non-existent column on feed handler in tickerplant

Community Support
1

Hi,

I have a requirement where the feed handler is sending data for less number of columns than that in the tickerplant and downstream subscribers.

My problem is the value for these columns are stored as empty list ().

How can I effectively convert these empty list to empty strings in tickerplant so that the same is saved in log as well as published to rdb etc.

I am on version 2.8.

Thanks,

Shatru.

2

.u.upd is implemented in the TP, which you can customize to put in the specific logic you need.

3

Hi Shatru,
Custom logic can be used to “intercept” a record before it gets to the main entry point of the tickerplant .u.upd.
Typically a well designed feedhandler will allow the function being called on the tp to be a configuration parameter, or indeed a string where it can define its own logic. However a few things must be considered before going down this route:

  1. Are the fields missing from the record being sent by the feed handler always missing the same fields, and if so are these missing fields always at the same location? If two different feed handlers are sending records to the same table, but the record they send are “variable” then you may run into issues.
  2. Are the missing fields meant to be character lists i.e. strings? Is their a potential that they are supposed to be other list types such as floats or integers?  Note that the first insert to an empty table with a list type defined then fixes that column type as in example below. Subsequently other inserts may fail.

    3) It is advised that this issue is fixed in the feedhandler but if it cant then the tp code should be wrapped with another script and an alternate entry point defined. eg:
    .myfeed.entry:{[t;x] if[t=`mytable;x:myfeed.fixtable[t;x];.u.upd[t;x]}
    where .myfeed.fixtable essentially contains logic to add the extra fields you need.
    This can also be accomplished by doing something similar to .u.upd. However that may have unforeseen consequences and I do not really advise that.
    Finally, adding logic like above to deal with edge cases for records adds load to the TP and may cause a performance hit, depending on how intrusive the logic to “fix” the record it.
    Regards,
    < >
    ////////////////////////////////////////////
    q)a:(a:();b:())
    q)`a insert (enlist 1 2;enlist 1 2.)
    ,0
    q)a
    a b
    -------
    1 2 1 2
    q)meta a
    c| t f a
    -| -----
    a| J
    b| F
    q)
    q)
    q)
    q)a:(a:();b:())
    q)
    q)`a insert (enlist “WW”;enlist 1 2i)
    ,0
    q)meta a
    c| t f a
    -| -----
    a| C
    b| I
    q)a
    a b
    --------
    “WW” 1 2

2:51 PM