Open cschwan opened 2 years ago
So, I guess we give up with the idea to add something during Grid::write
, and the log is added directly in memory (even if it's not dumped), isn't it?
@AleCandido Well, Grid::write
can't know if the other methods don't add to the log. But without a final Grid::write
the log wouldn't be written to disk, so effectively it does make the change. How would you propose to do it instead?
Nothing else, perfectly fine like this.
I simply thought that you would a written a log of writes, that of course would miss the information on the operations (and both multiple and no operations would be collapsed on a single one), but it would have been always present. So, even if you introduce a new method without adding the logging part, it could not escape the default logging on Grid::write
, but it's globally worse than your proposal.
The only other thing I can imagine at this point is to keep a separate "temporary log" as a Grid
attribute (or just different metadatum), containing only the logs of the current session, and then consume this information in Grid::write
.
In this way you can ensure logging in Grid::write
, but on the other hand it would have access to the whole session history.
The only drawback of this approach is the extra complication, that is not negligible.
The only other thing I can imagine at this point is to keep a separate "temporary log" as a
Grid
attribute (or just different metadatum), containing only the logs of the current session, and then consume this information inGrid::write
. In this way you can ensure logging inGrid::write
, but on the other hand it would have access to the whole session history. The only drawback of this approach is the extra complication, that is not negligible.
That's more or less what I was thinking about!
I guess something like this?
[
["Grid::convolute_eko", str(datetime.now()), __version__],
...
]
Exactly! That's we'd to have, right?
Maybe I would fix the element at four fields, with the last one a string containing method specific information (e.g. for Grid::convolute_eko
might be a hash of the operator, or some other kind of brief summary).
@AleCandido good idea!
Maybe I would fix the element at four fields, with the last one a string containing method specific information (e.g. for
Grid::convolute_eko
might be a hash of the operator, or some other kind of brief summary).
with an emphasis on brief ;-)
Most modifying operations should add an entry to the metadata serving as a log, containing
1) the operation that was performed 2) the date the operation and 3) the PineAPPL version that was used.
The following operations are interesting for us:
Grid::convolute_eko
in the generated FK-tableGrid::delete_bins
Grid::merge
Grid::merge_bins
Grid::optimize
Grid::scale
Grid::scale_by_order
Grid::set_remapper
Grid::upgrade
We don't want the following operations:
Grid::fill
,Grid::fill_all
Grid::set_key_value
Grid::set_subgrid