-
Notifications
You must be signed in to change notification settings - Fork 18
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
Quoted string in spec value should determine string type #41
Comments
Ok. And just to note that
Why are you using |
It seems that the generated companion object by tscfg has an My goal is to initialize the generated case class with the provided config file, but preserving strings without them being converted to bytes. ( |
So, this seems to be working as expected.
Now, perhaps what you need for your spec is to indicate (see #23 as indicated in the readme):
Please provide more details (perhaps a test case if more convenient) if I'm still not understanding the issue. Thx! |
Ah, overlooked your "preserving strings without them being converted to bytes. (memory: "50G" should be mapped to a memory val, with its value as String", sorry! In that case, both the spec |
I apologize if I did not explain myself very well. Yes, your last comment describes the issue accurately. But just to make sure we're on the same page and maybe to elaborate on the issue a bit: I have an application that needs the parameter
In both instances (quoted and unquoted string), tscfg converts the string to bytes. I did not expect this. Intuitively, my expectation is that if I specify an unquoted string, tscfg will convert it to bytes. However, if I specify a quoted string, it should be interpreted as a string, and not converted to bytes. This is the core issue. To get around this, I tried specifying the type explicitly ( |
Ah, I see now. Thanks for the key info. |
Seems like Typesafe-Config's API does not offer a way to distinguish between quoted and unquoted string values for things like
I would expect something like So, given that there's no API for the key check that would be needed here, looks like your Thoughts? |
Hi, was away for the past few days! What you're saying makes perfect sense. In that case, if I load |
Well, no. Loading The mechanism you indicate is for loading a concrete configuration, as opposed to a configuration spec: what you give tscfg is a configuration spec (where all the special syntax takes effect for the generation of the wrapper). What you give to If you are trying use the same configuration file for both cases (as the spec and the actual configuration instance) then note that this would be OK as long as no special tscfg syntax is used. Hope that helps as further clarification. |
I see. Yep, I see the difference now. In that case, I'm not sure tscfg should implicitly convert the string The problem with tscfg's implicit conversion is that in the generated class, a Moreover, it looks like tscfg already has a special syntax to allow the user to hint a size-in-bytes conversion. Thus, implicitly doing this does not seem warranted. Instead of having the |
Again, to parse the given config spec, tscfg relies on Typesafe Config, which, unfortunately, does not provide a way to differentiate between But I think you are making a good point. Perhaps tscfg should make an exception in its extraction logic and consider string values to just be of type |
I agree. Thanks for looking into this! To make sure we're on the same page, this is my suggestion: Is this what you're thinking? |
Yes, we're on the same page. |
Sure. Thanks! |
Suppose I have the following property in my
typesafe-config
file:the generated code using
tscfg
is:However, if I load the config first using Typesafe's
ConfigFactory.load()
method, and if I then initialize the generated class using thisConfig
object, I see this in the initialized object:Instead, I expect:
So it looks like despite generating the code correctly, initializing the generated class using a Typesafe
Config
object does not seem to parse the string correctly.I highly recommend that if a key has a quoted string value in the Typesafe config file, the code generator should not implicitly convert it to bytes. Of course, if it is an unquoted string, it should convert it to bytes as is done currently.
The text was updated successfully, but these errors were encountered: