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

[ALAIN MARI]

Thanks Boris for your answer.

I will ask our engineers to see how containers are used in our software (5 million loc ...)
and I will revert back to you if we have special needs.

Sometimes, maps can be advantageously replaced by sorted vectors.
Besides, I will try to maintain a vector/map in parallel in some of our persistent objects but I'm afraid of memory consumption in that case.
I will also look inside your odb::vector implementation to get a sense of the complexity, and to see I we can adapt it to std::list.

Regards.

Alain.


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.