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

Random related data #6

Closed
jjatria opened this issue Mar 8, 2017 · 1 comment · Fixed by #8
Closed

Random related data #6

jjatria opened this issue Mar 8, 2017 · 1 comment · Fixed by #8

Comments

@jjatria
Copy link

jjatria commented Mar 8, 2017

I came to this module trying to generate email addresses for fake people. This module has the necessary providers (ie. Internet), but is there any way to make it generate data that makes sense as a set?

Case in point: if I generate a person whose name is "Zachary Tinnel", it wouldn't make sense for this person to have the username "srodriguez" or the email "yoko75@bigwiz.net".

What I would like to do is something like this:

my $fake = Faker->new;
my $person = $fake->provider('Person');
my $internet = $fake->provider('Internet');

# Generate a random user
# eg. Zachary Tinnel
my %user = (
  first_name => $person->first_name,
  last_name => $person->last_name,
);

# Generate a related username. One of eg.
# ztinnel
# zachary.tinnel
# tinnel.zachary
# zachary85
$user->{user_name} = $person->username(%user);

# Generate a related email address.
# eg. <ztinnel@yahoo.com>, or <zachary85@foobar.net> 
$user->{email_address} = $internet->email_address(
  username => $user{user_name}
);

The way I imagine this working is that the argument to the functions that generate the fields would receive an optional hash as argument, and populate the used formats with the values received (or with random data, if left undefined). That way, the existing behaviour would remain unchanged, but the user would have the option of controlling the generated output.

What do you think?

@iamalnewkirk
Copy link
Contributor

I understand the ask but trying to account for stickiness and variability of each generator and how they might relate to other generators/providers would be a nightmare to support. A better approach (which I've used personally, professionally) is to create classes where the accessors and methods generate fake data and persist it (class attributes) where appropriate. Then you could related as much data as you want (as a set). Sorry for the delayed reply, I just refactored this library and will be releasing within the hour!

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