-
Notifications
You must be signed in to change notification settings - Fork 968
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keep config item order in ConfigObject #365
Comments
See #35 for discussion. With the heavy use of merging to support system props and default configs, it would be problematic in practice to make order meaningful in a Config. There is no way yet proposed to merge or override the order. Alternate solutions may be to use an array or put some type of priority number in an object. |
Hi, thanks for your reply! I read #35 and I see the difficulty we face. Yet I still think key ordering should be a "really-good-to-have" feature, so I'll try to give some thinkings on this topic. I see you mentioned it's hard to find certain intuitive principle about ordering, considering merging/withFallBack features. I understand the principle, if exists, must be simple and universal, so that it can be applied to every corner of the config library. I don't know the library deep enough like you, but I want to try from user's perspective to draw a principle: Rule A: What shows later is more important. The reverse rule is also effective: Rule B: What is more important shows later. Let me explain:
Take the scenario you described as example: reference.conf has keys in order a b c and application.conf has c a but doesn't specify b --- reference.conf ---
--- application.conf ---
The result should be:
The reasoning is that keys from application.conf should be more important than those of reference.conf, so items in reference.conf can be overrided. According to Rule B keys in application.conf should be at tail of merge result. It's easier to think if we imaginarily copy the two files together into same file, reference.conf over application.conf(according to Rule B), we can get the same result.
--- configZ ---
--- configY ---
--- configX ---
--- A.1 Result of configX.withFallBack(configY) ---
--- A.2 Result of configX.withFallBack(configY).withFallBack(configZ) ---
--- B.1 Result of configY.withFallBack(configZ)
--- B.2 Result of configX.withFallBack(configY.withFallBack(configZ)) ---
So A.2 == B.2. So in my consideration the principle is consistent and intuitive, however there is something I didn't considered though, which is config object equality you mentioned. I didn't understand the question well and I guess your meaning is that if we cannot draw a principle to unify key ordering of different associative operation result, then the equality would be broken. If the above principle can give us a stable result ordering, then we should not have to consider equality issue. I have to re-mention that I just considered this whole thing from user perspective and there may be some big mistake in my reasoning so please take this as a reference and I hope this can help implementing the key ordering feature sooner. |
Thanks for digging in on this! Some unit tests that are pretty relevant are these associativity tests here: It might be simple to add some that think about ordering, and see what can be made to work... A principle that's simply "order is what you would get if you pasted all the files into one and kept the last instance of each key" maybe works, though it's not going to be what people want sometimes perhaps... if you have Another issue that arises; say people use system property overrides like This is going to mean that any app that depends on key order has a "land mine" in wait for the unwary user who specifies |
The main usecase I see for ordering is that the user of the application has edited a user config, in the order that they wish it to be in, the application makes a modification to the config (for whatever reason, adding nodes during a software upgrade, changing based on user input) and the order of the file modified should be preserved where possible. If you are dumping the combined inherited results of multiple configs, I think the user will understand that their order might change slightly, but not be completely shuffled by a hash. |
There's a separate API intended for applications to modify configs fwiw |
#300 would mean supporting this in ConfigDocument (single doc parse tree level) |
@WilliamStone @havocp I'm going to fork this project and modify the map implementation used in ConfigObject from |
I forked this project and replace |
I’m glad that is working for you! For anyone considering that route, I’d advise that when relying on order you do not use The ConfigDocument API is the right way to extend the “strictly a parser” use case in the main codebase. It’s the API that gives you raw parse tree information rather than a “configuration object” |
In version 1.3.0 the map implementation used in ConfigObject is HashMap, which doesn't keep entry order. LinkedHashMap keeps order without significant performance hit. In certain cases config item order is important or very convenient to perform certain user control via config file. And keeping item order has no obvious harm IMHO. So I suggest replace HashMap by LinkedHashMap in ConfigObject.
The text was updated successfully, but these errors were encountered: