There is a method TMessage::EnableSchemaEvolution() which does nothing.
In case serialization and deserialization happen in programs linked against different versions of the library containing the class, the deserialization will fail. The only way is to send manually the streamerinfo.
Could you envisage to add support for schema evoluation when using TMessage ?
If yes, what would be the time until we get to use it ?
Cheers,
Barth
PS: TMessage::EnableSchemaEvolution() should be removed meanwhile because it is extremely misleading.
What do you mean by “TMessage::EnableSchemaEvolution() does nothing”?
It sets the data member fEvolution which is then used to activate the collection of the information needed for schema evolution.
When sending a message via a TSocket, the StreamerInfos are send via TSocket::SendStreamerInfos which is called from TSocket::Send.
Could you envisage to add support for schema evoluation when using TMessage ?
Yes, of course . It is already fully supported when sending via a TSocket.
The only way is to send manually the streamerinfo.
How are you sending the TMessage object. If you are not using TSocket, you will indeed need to reimplement the feature that it has to enable schema evolution See TSocket::Send and TSocket::SendStreamerInfos.
I see where the misunderstanding lays
We don’t use TSocket. We use TMessage to serialize and dump in a database. We use it again to deserialize.
When I said that it does “nothing” what I meant is that someone looking at the interface would expect the method EnableSchemaEvolution() to do more than setting a flag that another class will check. I expected the method to make my serialized object resistant to changes in the schema. In my opinion, this flag belongs to TSocket not TMessage.
I know that CMS does the same as us (ALICE), ie. reimplemented the storage of streamers along with their serialized object. I think it would be worth re-evaluating the design of this part of the code.
Even in this limited context, the flag does something and must be in TMessage. In order to even be able to send the StreamerInfo, you need to have the list of StreamerInfo available. Collecting this information is not ‘free’ and thus is disable by default. In the general case including all (or even just the needed) StreamerInfo in each TMessage is a very large (unnecessary) overhead. So in order to implement schema evolution you need to steps: (a) collecting (this the flags) and (b) send the ‘needed/missing’ StreamerInfo (this is done in TSocket).
In other words, to support schema evolution, you need to turn on the flag in TMessage and then (when not using TSocket) you can use the information given by TMessage::GetStreamerInfos() to store (or not) the StreamerInfos.
In regular operation, you would insure that each required StreamerInfo is send and/or stored only once per process and/or unit of works (i.e. each TFile for example).
[quote]I know that CMS does the same as us (ALICE), ie. reimplemented the storage of streamers along with their serialized object. I think it would be worth re-evaluating the design of this part of the code. [/quote]I am all for making your job easier ; I would need much more information to be helpful.
and dump in a database.
For example, picking up on that word, I would imagine that the ‘right’ solution in this case would be to have a table with 4 columns ( classname, streamer info version, streamer info checksum and streamerInfo content) in which each streamerInfo used anywhere in the database would be stored exactly once.
I like the idea of the table for streamer info in order to have them once and only once. Let me think a bit more about it and I will probably recontact you. Maybe we can have a coffee to discuss it further.
. It is already fully supported when sending via a TSocket.