config diff? about config

[havocp]

It's probably a lot easier to do this with the new withValue, atKey methods in 0.5.0 since they simplify building up ConfigObject instances. You would just recursively walk the two ConfigObject and compare child nodes with equals() and if they are different, add the difference to your diff I guess. Then to apply the diff you'd want to do replacement rather than the merging done by withFallback probably. i.e. recursively walk the old ConfigObject and if the diff contains a new value for any key, use the new value. I would recurse ConfigObject not Config because Config hides null values, and null values may be relevant. One trick is that the diff representation would need to have a representation for "value deleted". Comprehensive testing should be quite straightforward (a list of old/new pairs representing various cases, for each pair make sure applying the old/new diff to old results in new).

I think this is probably too special-purpose to put in the stock library, especially since it should be reasonably easy to implement oneself, but if we started to get repeated requests for it from different people maybe that could be reconsidered.

[havocp]

Oh, with respect to speed and cache, any kind of Config/ConfigObject modification is relatively slow at the moment because it's done by copying to a new Java HashMap. If the copying is done once on app startup it isn't a big deal but if you have something that really needs to be fast, it could matter. In theory we could reimplement ConfigObject with a custom map implementation designed to be immutable, and make it a lot faster. But that has not been done.

very good points; I did not notice you released 0.5.0 with new features; thank you!

re: "ConfigObject with a custom map" - would it make sense to expose map factory injection?

[havocp]

I wasn't thinking users of the config API could provide a custom map, but rather that internally we could implement a custom map and switch over to it rather than Java's standard mutable HashMap. Something like the immutable map in http://code.google.com/p/pcollections/ for example might be more efficient for an immutable-oriented API like ConfigObject. I'd likely code something a little smaller and more special-purpose than pcollections though. Anyway it isn't a high priority task necessarily since it's maybe a premature optimization until proven otherwise.

got it, thanks.

for those interested in a solution:

https://github.com/carrot-garden/carrot-config/tree/master/carrot-conf-diff

https://oss.sonatype.org/content/repositories/snapshots/com/carrotgarden/conf/carrot-conf-diff/

close for now