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

DOC: how to properly handle ADD of entity with conflicting primary key (email) #543

Closed
sglebs opened this issue May 6, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@sglebs
Copy link

sglebs commented May 6, 2024

Is your feature request related to a problem? Please describe.

I would like to see in the documentation the guidelines to deal with data entry. In my case, I am trying to add a USER object to the database, where the email is the primary key, and I am getting a "500/exception" because SQLAlchemy is properly flagging the invalid new record because these is already a USER with the same email (primary key).

Describe the solution you'd like

Just some example or doc that explains how to deal with data entry, including SAVE errors. It could be a NEW entity or an UPDATE (say, I change the guy's email).

Describe alternatives you've considered

I know there's the #before_create and #before_edit methods which I already use for some data validation. Should I do it in here? In the #before_create? Do a database query in #before_create and check?

Additional context
None

@sglebs sglebs added the enhancement New feature or request label May 6, 2024
@jowilf
Copy link
Owner

jowilf commented May 8, 2024

I know there's the #before_create and #before_edit methods which I already use for some data validation. Should I do it in here? In the #before_create? Do a database query in #before_create and check?

You can also catch the Exception. e.g:

def handle_exception(self, exc: Exception) -> None:

@jowilf jowilf closed this as completed May 17, 2024
@hasansezertasan
Copy link
Contributor

Somewhat related: #451

I think before_edit and before_create checks feels good.

I believe you could also implement a custom field for each unique columns and field types and use it instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants