Open jaredbeck opened 10 months ago
There is a precedent of existing features which help to generate consistent addresses:
en.faker.address.country_by_code
en.faker.address.postcode_by_state
Faker::Address.zip_code
accepts a state_abbreviation
(US-only, AFAICT)We could approach this problem by adding additional features like these, one at a time. For example, state_by_abbr
. Or, we could attempt something more grandiose, like a Faker::Address.consistent
method. The former could be built first, to support the latter. I'm open to any combination of these approaches.
I am still happy to attempt a PR, if this feature is approved. Thank you in advance for your feedback.
Hi, @jaredbeck ! Thanks for the in-depth description of the problem.
I agree that it would be nice to have basic consistency: the state should be located in the right country, and their names and abbreviations should match.
The problems that I see are:
Problem (1) can be solved by adding more information to locales, or reorganizing the data. Problem (2) is a bit harder to solve.
For this feature to work, would you need to pull information (state and abbreviation) from a different locale, depending on the country being generated?
And how would you approach problem 1 and 2?
Another option is to start small and just make sure that (country x country code)
match. Then figure out if (state x state_abbr)
is also possible. What do you think?
BTW: we are not accepting new generators and new locales at the moment, so this work should be limited to changing the existing generators and updating the existing locales.
It is difficult to generate an address meeting the basic standards of consistency. For example, we may want the
state
andstate_abbr
to match.Many systems perform basic validation of addresses. It would be convenient if
Faker::Address
could pass basic validation. I'd suggest that it is outside the scope of Faker to pass advanced validation, e.g. geocoding or postal-service validation.I tried using
full_address_as_hash
,We can see multiple inconsistencies in the above. For example, "US" does not match "Albania".
I am not proposing to change the behavior of
.full_address_as_hash
, it is just an example of an alternative I considered.It is possible for users to build their own "consistency layer" on top of Faker, but is not convenient.
I will be happy to attempt a PR, if this feature is approved.
For backwards compatibility, this new feature would be an addition, with no breaking changes.
I've deliberately avoided suggesting a new API, as I don't have any opinions about the names of e.g. new methods. I am just seeking feature approval at this point.