Back Midas Rome Roody Rootana
  Midas DAQ System  Not logged in ELOG logo
Entry  28 Jun 2021, Marco Francesconi, Suggestion, ODB Load in Sequencer 
    Reply  28 Jun 2021, Stefan Ritt, Suggestion, ODB Load in Sequencer 
    Reply  28 Jun 2021, Konstantin Olchanski, Suggestion, ODB Load in Sequencer 
       Reply  28 Jun 2021, Stefan Ritt, Suggestion, ODB Load in Sequencer 
          Reply  28 Jun 2021, Konstantin Olchanski, Suggestion, ODB Load in Sequencer 
             Reply  28 Jun 2021, Stefan Ritt, Suggestion, ODB Load in Sequencer 
                Reply  28 Jun 2021, Konstantin Olchanski, Suggestion, ODB Load in Sequencer 
                   Reply  28 Jun 2021, Marco Francesconi, Suggestion, ODB Load in Sequencer 
                      Reply  29 Jun 2021, Marco Francesconi, Suggestion, ODB Load in Sequencer 
                         Reply  30 Jun 2021, Stefan Ritt, Suggestion, ODB Load in Sequencer 
Message ID: 2245     Entry time: 28 Jun 2021     In reply to: 2244     Reply to this: 2246
Author: Stefan Ritt 
Topic: Suggestion 
Subject: ODB Load in Sequencer 
> > > > Hi all,
> > > > for my experiment we ended up with the need of changing lot of parameters (~9000 values) in the ODB at once by the sequencer.
> > > > The very first solution was to use a sequencer function with a ton of ODBSET calls, however a more elegant solution may be to provide an "ODBLoad" command which mimics the "load" command of odbedit.
> > > > I already have a working modification to the sequencer for this, if you agree I will commit it to a dedicated brach.
> > > > Let me know if you think this is a good approach.
> > > > 
> > > 
> > > Sounds like a good idea. I trust you are using the data in json format? Perhaps the command
> > > should be named "ODBLoadJSON" to be clear about this.
> > > 
> > > (JSON is preferred over .odb and .xml for many reasons (ask me))
> > 
> > What if some experiment keep some files in .xml format (ask me!). The routine should check for the extension and support all three formats.
> > 
> 
> Yes, hard to tell without seeing his full proposal, including the code. If it is load from file,
> sure we look at the file extension, I think the existing code already would do this and support all 3 formats.
> 
> But if he wants to load ODB data from a text literal or from a string,
> we might as well stick to json. I guess we could support the other formats, but I do not see anybody
> using anything other than json for new code like this.
> 
> ODBPasteJSON("/foo/bar/baz", '{"var1":1, "var2":"somestr"}');

I agree that if one would paste a string to the ODB, then JSON would be best.

But at MEG, we keep hundreds of XML files for configuration. Mostly historical, but that's how it is.

Stefan
ELOG V3.1.4-2e1708b5