ODB inline editor truncates stings

After the ODB inline editor used on the ODB page has been converted to the mjsonrpc interface, all changed string . An ODB string which has for example 256 chars, changes size to 10 if set to "midas.log" for example though the ODB page. This does NOT happen when done via the odbedit "set" command.

We had the discussion about string lengths already several times. I agree that a string in the ODB should get closer to std::string and change size when needed. But right now we still have code which links an ODB subtree to a C structure. Examples are /Runinfo in exprim.h and /Sequencer/State in the sequencer. If we now change for example the variable /Sequencer/State/Path through the web interface, the string length changes and the sequencer crashes, because the 1:1 mapping between the ODB and its C structure is broken.

Now one can argue that db_open_record() is not good, because it depends on an exact structure in the ODB. I know about this problem but I see no better solution right now. Replacing a db_get_record() with 100's of db_get_value is lots of work and can slow down the ODB access. So for the moment I would like to keep db_open_record() working as it is. Breaking this function via string length changes is right now a show stopper for me.

In order NOT to have the inline editor changing string lengths, a change in db_paste_json_node() would be required to my understanding. So we have to change

   bool is_array = (key.num_values > 1);
   if (tid == TID_STRING && is_array) {
      string_length = key.item_size;
   }

to

   if (tid == TID_STRING && strlen(str) < key.item_size) {
      string_length = key.item_size;
   }

But before I do that change, I would like to discuss it. The above code can increase strings if necessary, but does not shorten it. Most of our stings in "fixed" records have a size of 256, so most likely they will never be extended, and the record structure stays in sync with the C structure. The behaviour of the ODB web page is then similar than the odbedit "set" command. Later ("next year") we can the revisit this issue and redesign db_get_record/db_set_record.

Any opinions?

Comments (5)