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

Overriden form text field with FileUpload field. #723

Closed
2 tasks done
smbrine opened this issue Mar 4, 2024 · 7 comments
Closed
2 tasks done

Overriden form text field with FileUpload field. #723

smbrine opened this issue Mar 4, 2024 · 7 comments

Comments

@smbrine
Copy link

smbrine commented Mar 4, 2024

Checklist

  • The bug is reproducible against the latest release or master.
  • There are no similar issues or pull requests to fix it yet.

Describe the bug

Since I already have a solution but I don't know whether it's useful or not, I will be short. I have a simple logic in my app. User can upload a .json file, async def on_model_change(self, data, model, is_created, request): will open it, load json and pass it further as a dict to save it to postgres' JSONB field. The problem is that the SQLAdmin itself still considers it being of type UploadFile and hence line 689 in application.py was raising an AttributeError: 'dict' object has no attribute 'name'. My solution is to basically just pass f's value as is since there's no case when f can have name or read attribute in this elif.

Steps to reproduce the bug

No response

Expected behavior

No response

Actual behavior

No response

Debugging material

os, python, sqladmin version

Environment

  • OS: macOS Sonoma 14.2.1
  • Python: 3.11.3
  • SQLAdmin: 0.16.1

Additional context

No response

@aminalaee
Copy link
Owner

I think I understand what the issue is, but this was specifically added to make sqladmin work with fastapi-storages.
But I assume you are not using fastapi-storages but just using a FileUpload field, right?

@smbrine
Copy link
Author

smbrine commented Mar 6, 2024

Yeah, I use JSONB field in SQLAlchemy, override it with FileUpload field in the admin form, parse json from the file in the on_model_updateand pass the resulting data forward. According to my tests, there's no such case except for mine to get into the elif statement I changed. It also passes all the tests hence it's definitely not a destructive change!

@aminalaee

This comment was marked as outdated.

@aminalaee
Copy link
Owner

@smbrine I think I was a bit confused and my previous comment was not accurate.
The issue is that when uploading the file everything works es you explained, you open the file and pass the content as dict to be saved in DB.
The issue comes up when you want to edit the inserted object. You are storing the file content in JSONB but in the edit form you want to show FileField with WTForms. SQLAdmin expects that since this is a FileField, previously a file was stored for this.
Maybe a good question is why don'y you specify a TextField and validate the JSON with the hooks? Since you aren't really storing/editing the file.

@smbrine
Copy link
Author

smbrine commented Mar 7, 2024

Because in that case there will be no way to submit a file (except for fully custom form but it's definitely not what I want since it takes way more time to do).

@aminalaee
Copy link
Owner

But is this accomplished in any tool like Django admin and flask-admin without modifying the behaviour completely? The reason I ask is that is that this is a very specific use-case that you want the create form to accept a file, but in the edit form you want to edit a JSON field.

@smbrine
Copy link
Author

smbrine commented Mar 8, 2024

Seems like I have incorrectly explained my point. It's not that I want to have a JSON field in the edit form, there is also UploadForm since I don't want users to deal with TextAreas. The idea is for example if one wants to store, say, parseable text file in db in a parsed way (just like my case when I store .json file as JSONB instead of the file itself). I haven't used flask-admin, nor do I have expertise in Django admin hence I can't judge here. My point is that I have handled my specific scenario without affecting any other scenarios and now it's fully up to you but there's always a chance that there will be someone else who will also decide to override a field with a FileUpload!

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

Successfully merging a pull request may close this issue.

2 participants