SQLAlchemy unique constraint with prepopulated values

[MetaHG]

Hi!

I have a few questions regarding unique constraints set on some SQLAlchemy String(n) field.

Let's say I have the following model for the sake of example:

from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column

class User(Base):
    name: Mapped[str] = mapped_column(String(255), nullable=False, unique=True, index=True)

1. Will polyfactory only try to generate unique names through some string function in Faker using cls.__faker__.unique.[my_string_method] ?
2. What if we have an additional field code(name: Mapped[str] = mapped_column(String(5), nullable=False, unique=True, index=True)) in our model User ? As the faker instance is shared inside the factory I believe, it seems that the UniqueProxy of cls.__faker__ will be shared as well. While the size of the generated strings are different in that case, overlaps could be encountered if two unique fields of the same type are declared. Is it correct?
3. Given a factory that would need to operate on a prepopulated database, what would be the best way to avoid generating unique names that already belong to the database? Discussion Prevent duplicate items #569 may give an idea of a solution, but I am not sure that would be the best approach here. Note: some tables in my database basically behave like enums. In such a case, the prepopulated data that I am talking about corresponds to some sort of enum definitions. I would like a solution that either allows to re-use pre-populated ids for foreign keys when creating an instance of my factory, or that creates a new foreign key object that does not clash with the existing ones.

I could imagine something like the following for question 3.:

• Use the model of the factory to query the database for the specific field of the model and return all the existing items.
• Add these items to __faker__.unique._seen.
• Keep using __faker__.unique.generate_some_str_func
  This is just a rough sketch and this implementation would be brittle because _seen is not supposed to be exposed. Any better idea is welcomed.

Thank you for your help, and any examples or guidance would be greatly appreciated!

[adhtruong]

Hey @MetaHG , sorry for the slow reply!

1. No. Unique in this way in a db constraint rather than unique in the sense of items in a set
2. Same as above.
3. I'd use a similar method as linked. You can override the field on factory like example linked then apply custom logic at a field level
   1. Use random to randomly choose using existing or new
   2. If later, then can keep track on class itself with a set, repeatedly generating until not in here then reset in teardown. Or use faker as suggested that probably does similar under the hood but not exposed

Hope this helps! :)