Architecture #2012
closedThe historization of the group doesn't store if the group is static or dynamic
Description
So this information is not available for future use. It could be something useful to have.
Updated by François ARMAND about 13 years ago
- Target version changed from 18 to 2.4.0~alpha1
Updated by François ARMAND about 13 years ago
- Status changed from New to Discussion
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).
Updated by Jonathan CLARKE about 13 years ago
- Target version changed from 2.4.0~alpha1 to 2.4.0~alpha2
Updated by Jonathan CLARKE almost 13 years ago
- Target version changed from 2.4.0~alpha2 to 2.4.0~alpha3
Updated by Jonathan CLARKE almost 13 years ago
- Target version changed from 2.4.0~alpha3 to 2.4.0~alpha4
Updated by Jonathan CLARKE almost 13 years ago
François ARMAND wrote:
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).
This sounds great :)
I assume we're talking about 2.5 here though?
Updated by Jonathan CLARKE almost 13 years ago
- Assignee deleted (
Nicolas CHARLES)
Updated by François ARMAND almost 13 years ago
- Target version changed from 2.4.0~alpha4 to 24
Jonathan CLARKE wrote:
I assume we're talking about 2.5 here though?
Yes, clearly, it would be a rather big refactoring.
Updated by Jonathan CLARKE almost 13 years ago
- Status changed from Discussion to 2
- Assignee set to Nicolas CHARLES
- Target version changed from 24 to 2.4.0~alpha5
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.
Updated by Nicolas CHARLES almost 13 years ago
- Status changed from 2 to Pending technical review
- % Done changed from 0 to 100
Applied in changeset 41c65c74794066a195f6b1266ae8035024bc20d4.
Updated by Jonathan CLARKE almost 13 years ago
- Tracker changed from Bug to Architecture
Updated by François ARMAND almost 13 years ago
- Status changed from Pending technical review to Released
Seems OK.