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

Internet::Email with domain ignore the domain suffix when provided #1845

Closed
ngouy opened this issue Dec 2, 2019 · 11 comments
Closed

Internet::Email with domain ignore the domain suffix when provided #1845

ngouy opened this issue Dec 2, 2019 · 11 comments

Comments

@ngouy
Copy link
Contributor

ngouy commented Dec 2, 2019

#1808 introduced domain kw (thank you!) but does not test when a domain suffix is provied : it fails

Describe the bug

Faker::Internet.email(name: 'jane doe', domain: 'customdomain')
"doe_jane@customdomain.com" # ok

Faker::Internet.email(name: 'jane doe', domain: 'customdomain.com')
"jane_doe@customdomaincom.org" # KO

Expected behavior

when domain_suffix is proveded, keep it :

Faker::Internet.email(name: 'jane doe', domain: 'customdomain.com')
"jane_doe@customdomain.com"
@tiagofsilva
Copy link
Contributor

I think the method interface is quite confusing as it is. Let me point out some things that trouble me:

1 - Look at Faker::Internet.email(name: 'jane doe', subdomain: true, domain: 'customdomain.com') : param subdomain has a different type from domain when in practice they are supposed to work in a similar way. IMO. subdomain should be a string rather than a boolean, making it symmetric to its counterpart domain.

2 - the domain param was supposed to be symmetric to the domain_word method, which returns no domain suffixes. Therefore domain should not handle suffixes. There is nothing in the documentation stating that, but I just assumed that by looking at the code. This is by itself, clearly an interface problem, since we seem to understand things differently.

3 - Think about the different combinations we can have when filling domain and subdomain. subdomain = true and domain = 'domain.faker.com' should be doing what actually?

Suggestion to fix:
A change in the interface (I know, I know) to:
domain_name(legacy_subdomain = NOT_GIVEN, subdomain: nil, domain: nil, domain_suffix: nil)
Between subdomain, domain and domain_suffix, the one not supplied is generated automatically and we document it. Now, I think if the user, for ex., passes domain as "domain.com" (already with suffix) we ignore it (since it is documented that the method does not expect it).

Tell me what you think, please. Thanks! @vbrazo @olleolleolle @ngouy

@ngouy
Copy link
Contributor Author

ngouy commented Dec 4, 2019

I agree it's a really tricky one. This fix intened to fix it without breaking what is existing. 100% the interface should be updated

@ngouy
Copy link
Contributor Author

ngouy commented Dec 4, 2019

My only concern would be this line @tiagofsilva :

Now, I think if the user, for ex., passes domain as "domain.com" (already with suffix) we ignore it (since it is documented that the method does not expect it).

What do you mean by ignore it ? I think we should keep the .s as I may want to have a sub sub domain :

Faker::Internet.email(name: 'jane', subdomain: "sub.subdomain", domain: 'my.domain', domain_suffix: "fr.com") => ??

I think we should preserve the dot notation the user provide in its arguments
I think the above exemple should result to jane@sub.subdomain.my.domain.fr.com

I agree it should be ignored as following :

Faker::Internet.email(
  name:   'jane',
  domain: 'domain.com',
)
# => jane@random_subdomain.domain.com.fr

Another problem I see with the solution you gave is that I have to supply an empty subdomain if I want an email with your given domain. Exemple I want random_name@my_domain.com

Faker::Internet.email(
  domain:        'my_domain',
  domain_suffix: 'com',
)
# => random_name@random_subdomain.domain.com

Faker::Internet.email(
  subdomain:     '',
  domain:        'my_domain',
  domain_suffix: 'com',
)
# => random_name@my_domain.com

What do you think @tiagofsilva

@ngouy
Copy link
Contributor Author

ngouy commented Dec 4, 2019

what about the second part where you have to provide an empty subdomain if you don't want one @tiagofsilva ?

@tiagofsilva
Copy link
Contributor

Right, this is not ideal. But still better than what we have today IMO. But I have some ideas to suggest:

1 - subdomain default value could be empty string instead of nil.

2 - We could orchestrate subdomain value using another parameter, for instance has_subdomain or generate_subdomain. If the flag is true, no matter the value passed as subdomain, it would be generated. If the flag is false, subdomain would be required as we would have a guard clause to reinforce that.

3 - Another way to do it would be to really ignore subdomain if the param is nil. If something is passed, we concatenate to the domain name. The negative point here is that we would lose the ability to generate random subdomains as we have today. That part would be up to the user.

4 - We could allow a specific value, like :generated or :auto, as a default value for domain and domain_suffix while subdomain would be nil. Nil values would not generate anything. This should be very well documented though, as we don't have this kind of pattern in Faker library. But many other libs do have, like Rails and Hanami for instance.

I could be way off, so I think we need more opinions. Feel free to suggest them as well =).

@ngouy
Copy link
Contributor Author

ngouy commented Dec 4, 2019

I agree the better option is to stick to a boolean for the subdomain (so idea 2), default to false. If not false, we put a random generated subdomain to the email
If we want a "fixed" subdomain, we just have to pass it through the domain part

Faker::Internet.email(
  domain:        'my_domain',
) # => random@my_domain.random_suffix

Faker::Internet.email(
  domain:        'my_domain',
  domain_suffix: 'com',
) # => random@my_domain.com

Faker::Internet.email(
  generate_subdomain: true,
  domain:        'my_domain',
  domain_suffix: 'com',
) # => random@random_subdomain.my_domain.com

Faker::Internet.email(
  domain:        'my_subdomain.my_domain',
  domain_suffix: 'com',
) # => random@my_subdomain.my_domain.com

But indeed we have to carefully choose the var name generate_subdomain

the fourth one is too restrictive indeed and the last one just too hard to understand and use. Moreover Do we have other class api's with such options values (:auto, :generated, ...) ? I think it's important to be consistent with the rest of the code base, but I don't know it that much

@ngouy
Copy link
Contributor Author

ngouy commented Feb 5, 2020

@tiagofsilva PR is out there. Feel free to leave some comments. Even if it's not merged in the end it can be a good base to have discussions.

@Zeragamba
Copy link
Contributor

Testing locally, I noticed that the was fixed at some point:

irb(main):002:0> require 'faker'
=> true
irb(main):003:0> Faker::VERSION
=> "2.10.1"
irb(main):004:0> Faker::Internet.email(domain: "example.gov.uk")
=> "fredrick@example.gov.uk"

I'll see if I can figure out which version fixed it later (if no one else finds it)

@ngouy
Copy link
Contributor Author

ngouy commented Feb 6, 2020

The first PR referenced in this issue fixed it (#1846)

But @tiagofsilva wanted to point out the interface wans't clear enought. That what the second PR is all about

@thdaraujo
Copy link
Contributor

Hey, folks. In an effort to lighten our load as maintainers and be able to serve you better in the future, the faker-ruby team is working on cleaning out the cobwebs in this repo by pruning the backlog. As there are few of us, there are a lot of items that will simply never earn our attention in a reasonable time frame, and rather than giving you an empty promise, we think it makes more sense to focus on more recent issues. That means, unfortunately, that we must close this issue.

Don't take this the wrong way: our aim is not to diminish the effort people have made or dismiss problems that have been raised. If you feel that we should reopen this issue, then please let us know so that we can reprioritize it. Thanks!

@ngouy
Copy link
Contributor Author

ngouy commented Aug 8, 2022

all good, I think the issue was addressed

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

No branches or pull requests

4 participants