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

Issues with data types of IFSC.json #69

Open
himanshub16 opened this issue Apr 8, 2018 · 4 comments · May be fixed by #71
Open

Issues with data types of IFSC.json #69

himanshub16 opened this issue Apr 8, 2018 · 4 comments · May be fixed by #71

Comments

@himanshub16
Copy link

Currently, following is the data-type of IFSC.json:

{
    'bank_code (string)' : [ array of branch_code (int / string) ]
}

While this works in Python and JavaScript, there are issues writing modules for static-typed languages like Golang. I've been trying to manage this while writing a Go variant and caused chaos.

Proposed solution

A solution to this would be strictly using 6 digit string branch codes padded with zeros if required. This will avoid any representation of another size due to prefix zeros getting trimmed.

Using string data type would save a lot of effort and help use the JSON easily.

@captn3m0
Copy link
Contributor

That would also bump up the JSON size significantly. Any other suggestions?

@himanshub16
Copy link
Author

himanshub16 commented Apr 18, 2018

I tried to check the size of the database when all values are converted to strings by padding with zeros using this code > https://gist.github.com/himanshub16/0c528da5a8714d8ad56907da93c7ae85

The file size changed from 804 KB to 1.4 MB. Could this file size be considered okay?

Another solution could be removing data files from git. Git repo should only have the source code of the program. I have an example from Google's OAuth library where they download the public certificate (to verify JWT tokens) on the fly when they timeout/expire and keep a local copy for subsequent calls.

This too can download the json on first use. This would avoid publishing the package to npm/pypi everytime json updates and code remains same. This can be a solution to #68

Also, if this is not an issue internally and there are no other users, you can avoid taking this burden now. 😃

@captn3m0
Copy link
Contributor

Sounds like too much complexity/magic. I looked at how other data-specific projects do it, and the release approach we follow is similar. See https://github.com/stephenmathieson/node-tlds, https://github.com/googlei18n/libphonenumber, https://github.com/umpirsky/tld-list for eg.

If there is no other way to fix the type issue, we can enforce strings. We can still trim them though, right? The validator can pad and verify at run time?

@himanshub16
Copy link
Author

https://github.com/umpirsky/tld-list handles data files pretty decently (opinionated).

For type issue, we can surely enforce strings and trim them. That sounds great!

captn3m0 pushed a commit that referenced this issue May 3, 2018
@captn3m0 captn3m0 linked a pull request May 3, 2018 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants