-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Peewee now logs Errors that were previously caught #254
Comments
The only things peewee logs are:
So if you do not want these errors, you can just add a null handler to the logger: import logging
logger = logging.getLogger('peewee')
logger.addHandler(logging.NullHandler()) # suppress logging |
Thanks, do you have any insight in an alternative way to update a record on duplicate keys? |
I think the way you're doing it makes sense. Do I need to address anything else regarding the behavior of the logging? |
Adding a NullHandler() didn't seem to work, it's still logging every duplicate record insert error, here's my logging section definition in the module that calls the db stuff:
|
I use this technique a lot and know that the save() may or may not succeed, that's the whole point of catching it, I don't need to know about the error. I would however like to know about OTHER SQL errors that I may or may not be catching. This seems like I may need to change my technique for updating existing records so as to not run afoul of all these errors. |
Turns out I use the other technique (check for existence catch DoesNotExist then create) a lot more, so I just switched over to that. This is fine now, sorry for the trouble. |
You might try then
Sounds good! |
Attempting to insert a record and relying on the referential integrity of the database to tell you if a row is present is a very common use case. Having peewee spam the logger with this information (especially when it is caught) is silly. Imagine you are inserting 10 million rows into a database. About 10% of your records have duplicate keys in one table or another. Checking before every insert would double the amount of DB queries required to complete the task. Turning off logging for peewee is a nuclear solution to this issue since it will disable your ability to see any other useful messages. Also setting the level above error would essentially only permit critical messages to pass through. I really appreciate the detail which peewee uses for the logger and how easy it is to see what's going on. However sending an exception to the logger inside of the library doesn't allow your library user to properly handle the exception. Even though its caught, your logs would still be full of exceptions. |
I totally agree with the last comment. I'm fighting with the same issue. I don't want to lose all the error traces just to ignore something that is not an error. I don't want to miss the oportunity to tell you what a great framework. Good job. Thanks a lot. |
What would you like to see instead? |
I would prefer that peewee did not log the exception to the logger but instead allowed the project that includes peewee to handle and/or log the error. From the perspective of a library which is solely included in another project, peewee should not impair the ability of the project owner to appropriately catch and handle errors. I would expect the library to throw the exception and be done. |
That makes sense to me. |
Thank you! |
I think this has to do with the 2.1.5
sql_error_handler
. Previously to know if I should update a record I would try a save and catch a MySQL IntegrityError, then I would update any fields in the duplicate record like this:And this still works but now the peewee module is logging SQL errors:
I'd rather it didn't log those errors at all, but the only way to suppress them that I can see is to disable peewee logging at the logging.ERROR level and I don't think that's wise.
I like this technique better than doing a try
.get()
for each record and inserting on aDoesNotExist
exception catch, but I don't like all the errors, any way around it?The text was updated successfully, but these errors were encountered: