Rudder

In the same idea, knowing the request, for a dynamic group, may be important. And if the group was enabled or not.
But, we have to draw a line somewhere.

That information is already in the event-log database, even if it is in a rather non interesting way (we only keep deltas there, so that if we want to know the state at some point in the time, we have to rebuild the full history).

Oh, and that information will also be in the git history of all the serialized version of item, when http://www.rudder-project.org/foswiki/Development/Pi_cr_group_export_import is implemented. Again, the search format won't be really interesting.

That mean that we will keep more or less the same data three times around Rudder (and not really cheap datas).

Perhaps what we should have thought is a tighter integration of these two log so that we didn't have any data duplication, something like:

• when an item is created, I serialize it and save the result in <somewhere>
• there is a "create event" referencing the serialized thing

Then, for a modification:

• when an item is modified, I serialize it and save the result in <somewhere>
• there is a "modified event" referencing the serialized thing.

Same for deletion.

Then we can both have nice event log, with full details, and the full history of any property of any items (find all events for the item, look to the event just before the date of interest, unserialize the item, get the property).

Jonathan CLARKE wrote:

I assume we're talking about 2.5 here though?

Yes, clearly, it would be a rather big refactoring.

We decided that when upgrading Rudder from an older version that doesn't historize group type, we will add the column to the SQL table, and fill in all gaps with "Unknown". As we can't know what type the group was throughout history, we can't fill it - it's better to have no data than wrong data.

Applied in changeset 41c65c74794066a195f6b1266ae8035024bc20d4.

Seems OK.