Closed antipopp closed 11 months ago
In all honesty, I try to avoid making assumptions about the data type based solely on the key string, unless the type is very evident (such as with an email address). This is because different naming conventions and customizations can lead to unexpected results.
Additionally, auto-incremented numbers for IDs are quite common, so it may be best to leave this decision up to the user, they can specify their preferences through their swagger definition.
Additionally, auto-incremented numbers for IDs are quite common, so it may be best to leave this decision up to the user, they can specify their preferences through their swagger definition.
I don't get your point. If not with format uuid
this package generates text slugs. It's not much of an assumption, I can't think of any use case where a field called id
should not be a unique identifier and the only option with faker would be using a uuid
, which will at least suffice at generating unique strings (as we're formatting strings with this method).
Well uuid is just one kind of unique id among manys, there are people using uint64(have to be string), hashes, or custom int to string mappings, etc. That's why I don't want to always use uuid here.
Well, then this PR is useless. Thanks for clarifyng.
I don't know how much on purpose was this choice, but this library generates UUID only for strings with a specified UUID format. Considering most of the times a string property named
id
or ending with_id
is a UUID or at least some kind of unique identifier, I consider this PR useful.I'm open to critics and other considerations regarding this.