-
-
Notifications
You must be signed in to change notification settings - Fork 179
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Create Ash module to deal with file
resources / uploads.
#1052
Comments
I love this, but I think it should be added as a configurable extension with multiple strategies ala ash authentication. |
@jimsynz could you say more? Waffle ecto allows for s3 and local - if you are referring to multiple storage providers. If you are referring to blob datatypes, I wonder if that would better fall under repos like ash_postgres. This at the very least could be an interim tool. What other strategies would you like to see? |
Its interesting...if it can be encapsulated with a type then it should probably be done fully within the bounds of a type as opposed to an extension, but we'll really have to see how it takes shape. |
I think let's start with the type-first approach you've got here, and see how far it can go. For now, let's call it |
Is your feature request related to a problem? Please describe.
Ash is great. We're missing interacting with files! I'm open to contributing at the very minimum an MVP to solve this 馃槃
Describe the solution you'd like
Use waffle_ecto under the hood for new module `AshFile.Resource.
Create a composite type
{:file, MyApp.Uploader.Foo}
With a composite type of
{:file, :uploader}
:waffle_ecto's
Uploader
resource definition with ash integration.MyApp.Avatar.Type
across multiple resources:uploader
types auto-added to custom ash typesAshFile.Resource
, all arguments defined in relevant sections in related module, centralizing logicDescribe alternatives you've considered
With a inline singleton to an Ash.Resource:
Macro expansion could define sub-module
Uploaders
with embedded waffle_ecto resource,with
use Ash.Resource, extensions: [Ash.File]
for 1-1 mapping and feature parity withwaffle_ecto
.Definitely way more implementation work up-front to get MVP ready (for me), but seems more
ash
design-compliant than composite type approach.
This would allow us to define a global
ash_files
extension api with defaultoptions, override-able at attribute level.
E.g:
Express the feature either with a change to resource syntax, or with a change to the resource interface
Due to extent of change, I'd like to get to an agreement on API design before filling this section out if ok.
Additional context
I'm currently leaning towards the composite approach due to less time needed for
implementation, but the decision in the end is ultimately left up to @zachdaniel 馃槃
The text was updated successfully, but these errors were encountered: