In certain case and for certain objects it may be beneficial to use a hashmap (e.g., std::unordered_map) instead of the default std::map for session's object cache. The idea is to allow specifying the desired template (with std::map-like interface) using the session pragma:
#pragma db object session(std::unordered_map)
class person
{
...
};
We can recognize std::map and std::unordered_map and add necessary includes. For other templates, the user will have to add the include via prologue. We would also probably want to add the --session-map option in addition to --generate-session.
Implementation-wise, feels like the easiest is to typedef the map in the generated object_traits. Note also that there is disabled experimental code in <odb/session.hxx> that selects between std::map and std::unordered_map depending on whether the id type is hashable. While it seems to work (all tests pass), this approach was deemed too implicit. But it shows that std::unordered_map's interface is sufficiently compatible for our needs.
In certain case and for certain objects it may be beneficial to use a hashmap (e.g.,
std::unordered_map) instead of the defaultstd::mapfor session's object cache. The idea is to allow specifying the desired template (withstd::map-like interface) using thesessionpragma:We can recognize
std::mapandstd::unordered_mapand add necessary includes. For other templates, the user will have to add the include via prologue. We would also probably want to add the--session-mapoption in addition to--generate-session.Implementation-wise, feels like the easiest is to
typedefthe map in the generatedobject_traits. Note also that there is disabled experimental code in<odb/session.hxx>that selects betweenstd::mapandstd::unordered_mapdepending on whether the id type is hashable. While it seems to work (all tests pass), this approach was deemed too implicit. But it shows thatstd::unordered_map's interface is sufficiently compatible for our needs.