ereuse/devicehub-django
8
0
Fork 0
Code Issues 6 Pull requests 6 Packages Projects Releases Wiki Activity

Parsing error handling and MAC retrieval on new snapshots #27

Merged
pedro merged 12 commits from pr_25 into main 2024-11-12 13:57:05 +00:00
Conversation 4 Commits 12 Files changed 6 +58 -47
pedro commented 2024-11-10 02:35:05 +00:00
Owner
Copy link

we try again the merge of #25

we try again the merge of https://farga.pangea.org/ereuse/devicehub-django/pulls/25
pedro added 3 commits 2024-11-10 02:35:06 +00:00
pedro requested review from cayop 2024-11-10 02:35:36 +00:00
rskthomas added 3 commits 2024-11-11 07:29:25 +00:00
rskthomas added 3 commits 2024-11-11 17:50:12 +00:00
rskthomas added 1 commit 2024-11-11 17:58:29 +00:00
rskthomas commented 2024-11-11 18:02:32 +00:00
Owner
Copy link

Done again PR #25.

Also reworked the exception handling and error messages on upload/import views.

Added a success message to display for these views.

Changed form validation onto the fields, because if the form itself failed but the file was read, then the file_input field showed a success icon (whilst displaying error messages), which is confusing given that it is the only field.

Done again PR #25. Also reworked the exception handling and error messages on upload/import views. Added a success message to display for these views. Changed form validation onto the fields, because if the form itself failed but the file was read, then the file_input field showed a success icon (whilst displaying error messages), which is confusing given that it is the only field.
rskthomas changed title from WIP: Parsing error handling and MAC retrieval on new snapshots to Parsing error handling and MAC retrieval on new snapshots 2024-11-11 18:02:36 +00:00
pedro commented 2024-11-12 00:38:19 +00:00
Author
Owner
Copy link

I am confused by the raises in proposed code (I also found other ones in the current django app), maybe the use of raise you are doing here is fine, just review it again. Because I saw how a generic rise in django command crashed the application, but maybe when you use this kind of raise everything is fine https://docs.djangoproject.com/en/dev/ref/exceptions

I found a portion of the code that it is old (with other parts might happen the same!), this part; we don't need. We don't need the if settings.DEBUG anymore, we have a logger configuration that when DEBUG is there, a trace is always generated. And the old message is shorter and clearer than the new one. Done here -> fc849f0360

I am confused by the raises in proposed code (I also found other ones in the current django app), maybe the use of raise you are doing here is fine, just review it again. Because I saw how a generic rise in django command crashed the application, but maybe when you use this kind of raise everything is fine https://docs.djangoproject.com/en/dev/ref/exceptions I found a portion of the code that it is old (with other parts might happen the same!), this part; we don't need. We don't need the if settings.DEBUG anymore, we have a logger configuration that when DEBUG is there, a trace is always generated. And the old message is shorter and clearer than the new one. Done here -> https://farga.pangea.org/ereuse/devicehub-django/commit/fc849f0360dc0e9aad251c18cab8b7e441a1c0fa
pedro added 1 commit 2024-11-12 13:33:16 +00:00 
- We don't need the if settings.DEBUG anymore, we have a logger
configuration that when DEBUG is there, a trace is always generated
- restore old error message that is shorter and clearer than the new one
pedro added 1 commit 2024-11-12 13:38:21 +00:00 
specially, do not halt in case of errors, just print them in logs
pedro commented 2024-11-12 13:40:55 +00:00
Author
Owner
Copy link

Reviewed raises with @cayop ( 57f9e28466 )

@cayop needs to test it before merge

Reviewed raises with @cayop ( https://farga.pangea.org/ereuse/devicehub-django/commit/57f9e28466f11ec7903f5f55ddedfbb2648b42d9 ) @cayop needs to test it before merge
pedro changed target branch from real_main to main 2024-11-12 13:46:11 +00:00
pedro force-pushed pr_25 from 57f9e28466 to 65788b36af 2024-11-12 13:49:05 +00:00 Compare
pedro merged commit b7d7b9041d into main 2024-11-12 13:57:05 +00:00
pedro deleted branch pr_25 2024-11-12 13:57:07 +00:00
rskthomas commented 2024-11-12 14:00:53 +00:00
Owner
Copy link

Ive use the exceptions mostly to catch the errors and propagate them with a cleaner message (for ValidationError to display). Mostly because those are shown to the user, which may not know what did wrong. If there is a better and more idiomatic way of raising errors let me know as im new to django.

Ive use the exceptions mostly to catch the errors and propagate them with a cleaner message (for ValidationError to display). Mostly because those are shown to the user, which may not know what did wrong. If there is a better and more idiomatic way of raising errors let me know as im new to django.
Sign in to join this conversation.
Reviewers
No reviewers
cayop
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: ereuse/devicehub-django#27
No description provided.
Delete branch "pr_25"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?