Sysrepo loads too much data when editing a single leaf

[trentzhou]

I was playing around the "REDIS DS" plugin. I added a breakpoint at the function srpds_redis_load, and then tried to change a leaf with sysrepo-cli. After commit, I saw function srpds_redis_load was called. This was good.

But the parameter xpaths was NULL, and xpath_count was 0. Here is the call stack:

libsysrepo.so.7!srpds_redis_load(const struct lys_module * mod, sr_datastore_t ds, const char ** xpaths, uint32_t xpath_count, void * plg_data, struct lyd_node ** mod_data) (/home/trent/code/sysrepo/src/plugins/ds_redis.c:3048)
libsysrepo.so.7!sr_module_file_data_append(const struct lys_module * ly_mod, const struct sr_ds_handle_s ** ds_handle, sr_datastore_t ds, const char ** xpaths, uint32_t xpath_count, struct lyd_node ** data) (/home/trent/code/sysrepo/src/common.c:5377)
libsysrepo.so.7!sr_modinfo_module_data_load(struct sr_mod_info_s * mod_info, struct sr_mod_info_mod_s * mod, const char * orig_name, const void * orig_data, uint32_t timeout_ms, sr_get_oper_flag_t get_oper_opts, int run_cached_data_cur) (/home/trent/code/sysrepo/src/modinfo.c:2464)
libsysrepo.so.7!sr_modinfo_data_load(struct sr_mod_info_s * mod_info, int read_only, const char * orig_name, const void * orig_data, uint32_t timeout_ms, sr_get_oper_flag_t get_oper_opts) (/home/trent/code/sysrepo/src/modinfo.c:2747)
libsysrepo.so.7!sr_modinfo_consolidate(struct sr_mod_info_s * mod_info, sr_lock_mode_t mod_lock, int mi_opts, uint32_t sid, const char * orig_name, const void * orig_data, uint32_t timeout_ms, uint32_t ds_lock_timeout_ms, sr_get_oper_flag_t get_oper_opts) (/home/trent/code/sysrepo/src/modinfo.c:2845)
libsysrepo.so.7!sr_apply_changes(sr_session_ctx_t * session, uint32_t timeout_ms) (/home/trent/code/sysrepo/src/sysrepo.c:3952)
libsysrepo-cpp.so!sysrepo::Session::applyChanges(std::chrono::duration<long, std::ratio<1l, 1000l> >) (Unknown Source:0)
SysrepoAccess::commitChanges(SysrepoAccess * const this) (/home/trent/code/cli-projects2/netconf-cli/src/sysrepo_access.cpp:157)
boost::apply_visitor<Interpreter, boost::variant<boost::detail::variant::over_sequence<boost::mpl::l_item<mpl_::long_<18l>, cancel_, boost::mpl::l_item<mpl_::long_<17l>, cd_, boost::mpl::l_item<mpl_::long_<16l>, commit_, boost::mpl::l_item<mpl_::long_<15l>, copy_, boost::mpl::l_item<mpl_::long_<14l>, create_, boost::mpl::l_item<mpl_::long_<13l>, delete_, boost::mpl::l_item<mpl_::long_<12l>, describe_, boost::mpl::l_item<mpl_::long_<11l>, discard_, boost::mpl::l_item<mpl_::long_<10l>, dump_, boost::mpl::l_item<mpl_::long_<9l>, exec_, boost::mpl::l_item<mpl_::long_<8l>, get_, boost::mpl::l_item<mpl_::long_<7l>, help_, boost::mpl::l_item<mpl_::long_<6l>, ls_, boost::mpl::l_item<mpl_::long_<5l>, move_, boost::mpl::l_item<mpl_::long_<4l>, prepare_, boost::mpl::l_item<mpl_::long_<3l>, quit_, boost::mpl::l_item<mpl_::long_<2l>, set_, boost::mpl::l_item<mpl_::long_<1l>, switch_, boost::mpl::l_end> > > > > > > > > > > > > > > > > > >>&>(Interpreter const&, boost::variant<boost::detail::variant::over_sequence<boost::mpl::l_item<mpl_::long_<18l>, cancel_, boost::mpl::l_item<mpl_::long_<17l>, cd_, boost::mpl::l_item<mpl_::long_<16l>, commit_, boost::mpl::l_item<mpl_::long_<15l>, copy_, boost::mpl::l_item<mpl_::long_<14l>, create_, boost::mpl::l_item<mpl_::long_<13l>, delete_, boost::mpl::l_item<mpl_::long_<12l>, describe_, boost::mpl::l_item<mpl_::long_<11l>, discard_, boost::mpl::l_item<mpl_::long_<10l>, dump_, boost::mpl::l_item<mpl_::long_<9l>, exec_, boost::mpl::l_item<mpl_::long_<8l>, get_, boost::mpl::l_item<mpl_::long_<7l>, help_, boost::mpl::l_item<mpl_::long_<6l>, ls_, boost::mpl::l_item<mpl_::long_<5l>, move_, boost::mpl::l_item<mpl_::long_<4l>, prepare_, boost::mpl::l_item<mpl_::long_<3l>, quit_, boost::mpl::l_item<mpl_::long_<2l>, set_, boost::mpl::l_item<mpl_::long_<1l>, switch_, boost::mpl::l_end> > > > > > > > > > > > > > > > > > >>&)(boost::variant<boost::detail::variant::over_sequence<boost::mpl::l_item<mpl_::long_<18>, cancel_, boost::mpl::l_item<mpl_::long_<17>, cd_, boost::mpl::l_item<mpl_::long_<16>, commit_, boost::mpl::l_item<mpl_::long_<15>, copy_, boost::mpl::l_item<mpl_::long_<14>, create_, boost::mpl::l_item<mpl_::long_<13>, delete_, boost::mpl::l_item<mpl_::long_<12>, describe_, boost::mpl::l_item<mpl_::long_<11>, discard_, boost::mpl::l_item<mpl_::long_<10>, dump_, boost::mpl::l_item<mpl_::long_<9>, exec_, boost::mpl::l_item<mpl_::long_<8>, get_, boost::mpl::l_item<mpl_::long_<7>, help_, boost::mpl::l_item<mpl_::long_<6>, ls_, boost::mpl::l_item<mpl_::long_<5>, move_, boost::mpl::l_item<mpl_::long_<4>, prepare_, boost::mpl::l_item<mpl_::long_<3>, quit_, boost::mpl::l_item<mpl_::long_<2>, set_, boost::mpl::l_item<mpl_::long_<1>, switch_, boost::mpl::l_end> > > > > > > > > > > > > > > > > > > > & visitable, const Interpreter & visitor) (/usr/include/boost/variant/detail/apply_visitor_unary.hpp:66)
main(int argc, char ** argv) (/home/trent/code/cli-projects2/netconf-cli/src/cli.cpp:299)

My concern is: the data change only happens on a single leaf, does sysrepo really have to reload all the data in this module? Is it possible to only load necessary data?

[michalvasko]

Is it possible to only load necessary data?

How do you know what data are necessary? Because of validation, the whole data tree is loaded, only foreign dependencies (in other modules) are tracked. Node-level dependency tracking is not implemented.

[trentzhou]

Thanks @michalvasko. Is there any plan to support node level dependency tracking?

[michalvasko]

No, it would require major effort with uncertain results.