SDataBase Hierarchy

[brian soe]

From a user perspective (non-functional), the following Database hierarchy is more intuitive:

SDataBase.robots_.at(robot_name)->s_io_

SDataBase.robots_.at(robot_name)->s_parser_

SDataBase.robots_.at(robot_name)->s_controller_

SDataBase.s_gui_

SDataBase.sim_ticks_

SDataBase.time_

then

SDataBase.s_io_.at(robot_name)

SDataBase.s_parser_.at(robot_name)

SDataBase.s_controller_.at(robot_name)

SDataBase.s_gui_

SDataBase.sim_ticks_

SDataBase.time_

What do other people think?

[Samir Menon]

I don't think so.

1. Both s_io_ and s_parser_ contain a LOT of information that isn't directly related to a robot.

2. Your definition of SDataBase.robots_ mixes a lot of "static" data with "dynamic" data. This is a bad idea. Eg. s_parser_ is "static" by design. i.e., It can support multiple readers with no race conditions.

3. s_controller_ is more debatable. I'll open a separate bug about it.

[Samir Menon]

See discussion.

[brian soe]

I agree that there is some parser data that does not belong in robot. Let me revise:

SDataBase.robots_.at(robot_name)->s_io_ SDataBase.robots_.at(robot_name)->s_parser_ SDataBase.robots_.at(robot_name)->s_controller_ SDataBase.s_gui_ SDataBase.s_graphics_worlds_ SDataBase.sim_ticks_ SDataBase.time_

But in s_io_, I only see one member, which is for robot IO. sutil::CMappedList<std::string, SRobotIO> io_data_;

It would be more intuitive for parsed data such as initial configuration, joint limits, torque limits, etc to be properties of the robot. If the data is meant to be static, then get() functions could prevent direct access. Would this cause significant performance problems?

[brian soe]

I have another questions regarding this issue.

[Samir Menon]

This is mostly refactored in a way that allows the code to operate without SDatabase. So the point is moot.