search

razorpay / ifsc

:bank: IFSC Codes Repository
https://ifsc.razorpay.com
MIT License
330 stars 129 forks source link

Issues with data types of IFSC.json #69

Open himanshub16 opened 6 years ago

himanshub16 commented 6 years ago

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 commented 6 years ago

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

himanshub16 commented 6 years ago

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. :smiley:

captn3m0 commented 6 years ago

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 commented 6 years ago

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!