[odb-users] Change-tracking map, list and set containers

[Boris Kolpackov]

ALAIN MARI <alain.mari at se.com> writes:

> In particular, we have many classes with huge std::map containers inside.
> I saw in the SQL execution plan that an update of such a class required
> the full rebuilt of the entire jointure table in SQL db.
> 
> Is there some kind of change-tracking or smart map container in a future
> version of ODB (same as vector)?

We looked into it but change-tracking containers are not exactly trivial
to implement, especially if you want to do this efficiently. Look at the
vector's implementation to get a sense of the complexity involved.

On the other hand, if you make some application-specific assumptions
(e.g., elements are never removed) or accept some inefficiency, then
an application-specific implementation can be provided relatively easily.

Another interesting possibility is to come up with some kind of a hybrid
container that uses the change-tracking vector for database interfacing
and std::map as its API (from the database storage point of view, map is
just a sequence). How well this will work depends on how you use your
maps (again, application-specific knowledge). For example, if all the
modifications go through your object's API, then you could just add
the vector data member next to the map and maintain both in parallel.