[patch] ChangesetCache: Is it useful as it is? Why isn't it always used?

[GerdP]

Just some thoughts...
We have a lot of dialogs which handle changeset data, but only some use the in-memory cache implemented with class ChangesetCache. I wonder if this is intended or not. We also have a lot of different implementations to download changeset data.
We have at least three dialogs:

• History Browser (HistoryBrowserDialog)
• Changeset Manager (ChangesetCacheManager)
• Changesets side pane (ChangesetDialog)

Each seems to implement methods to download changeset data and some seem to use multifetch ignoring the cache while others use the cache but fill it only with singe GET requests.
Quite confusing!
Esp. the Histoy Browser bypasses the cache and possibly downloads huge amounts of data, e.g. when the user browses the history of a complex route relation with many members and many versions.

Besides that we have the reverter plugin which implements its own set of tasks to download history data and I think it also always bypasses the cache.

My conclusion so far: The cache is not very useful as it is, but a better implementation using a disk cache could help to prevent hitting the rate limits.

[stoecker]

I'd say. Legacy code ;-)

[GerdP]

There's also a problem with the id of a changeset. In most places we store it as int, in others we use long, e.g. HistoryOsmPrimitive. Seems useless when class Changeset uses int, right?

[gaben]

Marcello noticed this as well sometime ago, see ticket:21570#comment:13.

[GerdP]

use/update ChangesetCache when downloading changeset in HistoryBrowser

[GerdP]

In 19098/josm:

fix #23645: ChangesetCache: Is it useful as it is? Why isn't it always used?

• use/update ChangesetCache when downloading changeset in HistoryBrowser

[GerdP]

I have no idea how much work it would be to change the field HistoryOsmPrimitive.changesetId from long to int.
HistoryOsmPrimitive is used in plugins, at least reverter and undelete and I assume we would see binary incompatibilities if we change the field in core.
Same problem with HistoryOsmPrimitive.version (also long instead of int)
I am not sure but I think the problem is small, it seems instances of HistoryOsmPrimitive are only stored temporary.

[gaben]

Replying to GerdP:

I assume we would see binary incompatibilities if we change the field in core

Bump min version? DevelopersGuide/DevelopingPlugins#ThemanifestfileforaJOSMplugin

[GerdP]

Yes, sure, we could do that, but the benefit seems very small and thus I see no need to work on the change as long as we don't start to store instances of HistoryOSMPrimitive in a cache.