Skip to content
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

Number string is converted to int #50

Closed
brabanod opened this issue Nov 15, 2023 · 5 comments · Fixed by #51
Closed

Number string is converted to int #50

brabanod opened this issue Nov 15, 2023 · 5 comments · Fixed by #51
Labels

Comments

@brabanod
Copy link

When I define a variable in my .env file like this:

MyVar = "0001"

This will be translated by arkana into an integer with the trailing zeros being removed.

@inline(__always)
public let myVar: Int = {
    let encoded: [UInt8] = [
        0xa8, 0x5, 0x7, 0xf1
    ]
    return ArkanaKeys.decode(encoded: encoded, cipher: ArkanaKeys.salt)
}()

What I need however is to have the exact same string "0001" when I access myVar in the code. Is this a bug or is there a way to force parsing as string?

@brabanod
Copy link
Author

brabanod commented Nov 15, 2023

Seems like the code that is causing this is the regular expression in lib/arkana/models/type.rb

when /^\d+$/
    INTEGER

Is there any way to prevent arcana from doing this? I could of course add a character in front of my value like a0001 so that arkana will handle it like a string, however then I have to remove that character again in the code. It's not a very nice solution. Are there any solutions known to this problems, which can be configured directly in arkana?

@rogerluan
Copy link
Owner

Hi @brabanod 👋

It seems like you're the first person to request this type of behavior. Aside from the solution you proposed of adding an extra character, I see two other solutions that could be built into Arkana itself:

  • Add an env var that, when set, changes this default behavior
  • Compare if the string being read ("0001") is equal to its numeric representation after converting it (e.g. 1 in your case). If it's not, parse it as a String instead.

What do you think of these solutions? I lean towards less configurations (thus, less env vars), but not sure if the 2nd solution has any pitfalls I'm not seeing, that could potentially break people's code if they're using it 🤔 perhaps thinking of edge cases like massive numbers (larger than 64-bit) could break this unintentionally? What about negative numbers? I suppose these are already not supported anyway.

Let me know what you think :)

@rogerluan
Copy link
Owner

I opened a PR with the 2nd implementation above, and added extensive tests to cover the scenarios I could think of. Let me know if that works for you @brabanod 😃

@brabanod
Copy link
Author

brabanod commented Jan 3, 2024

Hey @rogerluan, sorry for the late response!
The second solution looks perfect. Thank you very much for taking the time to implement it, really appreciate it! Just tested it with the latest version and everything works perfectly fine 🎉

@rogerluan
Copy link
Owner

Amazing, I'm glad it helped you! Thank you for your feedback @brabanod 🤗 really appreciate it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants