-
Notifications
You must be signed in to change notification settings - Fork 149
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
Scope id not available on insert with auto generated uuid #15
Comments
To be honest I haven't worked with UUIDs in Ecto yet, and you're right. The use cases I have built Arc with were mostly geared towards adding attachments or images to existing models. Given that, I am open to having a better workflow for uploading during creation of the model itself, but I haven't had the time to investigate what a clean implementation would look like. If you can get Ecto to assign the UUID prior to Alternatively, you can insert the model and then add the attachment immediately after, as in #7 |
Hi Stavro, Thanks for the advice, adding the id in the changeset prior to cast_attachments as another cast did work but would have implications to updates as it always sets the id field. This isnt a problem for me as I wont be updating but its not really ideal. I don't wanna start branching and adding features you disagree with (if I even can, as I said i'm an elixir/ecto newbie). But I thought that it would be useful was if the result of arc's store method returned a map with the filename and a generated uuid or some other unique id to be used in the definition methods. This would avoid having to have the models id available, so things like this could be used in the definition:
This would need to be stored similar to the timestamp something like. [image]|[UniqueIdentifier]?[Timestamp] i.e. photo.jpg|c796ae4a-636f-4e03-9129-419ccdd47cdf?1234321 Not sure how you feel about such a solution, does it even make sense :) Whats your thoughts? Chris |
@stavro So I had a stab at what I proposed, and it seems to work well for my use case. I'm hesitant to raise a PR both because my elixir skills suck and I was unsure if you even agreed with this idea. Anyway, for reference here are my forks: master...chrisjowen:master Summary is that Arc.File defstruct now has an identifier key. When its 'new' function is invoked it's given the value of a UUID. When Arc.Actions.Store.store is called it returns {file_name: xxx, identifier: xxx} instead of just the file name and arc_ecto uses this as I described before. Chris |
@chrisjowen I added a uuid to the change set directly in my ecto model it works well enough. I just check to only set it if its not already set. https://github.com/digitalcake/digitalcakes_tmp/blob/master/web/models/post.ex#L27 |
@DigitalCake cheers I thought of this in the first place. But I didn't like the idea of manually having to add a unique identifier to my model. If I added more files to the model I'd end up having several file identifiers properties. I just wanted this to be handled for me. |
@DigitalCake I just went the same way and it worked perfectly. Thanks! |
@DigitalCake do you still have those examples? |
@igorbelo Here is an example of model that works for me.
And the Hello.Avatar module
|
For anyone who comes here finding that they can't replace their attachment in a changeset: you'll get the previous attachment (you can access it in your changeset via |
Hey,
So looking at the examples here is seem that everything is geared towards adding an image to an existing ecto model. I have an endpoint that uploads an image and some meta data and I would like to create the model and upload the image to S3 with the storage directory "uploads/#{scope.id}".
The problem is that at the time of insert the scope has no id, and I assumed that using server side generated uuids would fix this as the id is present before insertion. Im new to ecto/elixir/everything here so I dont understand the lifecycle that your working with, but is there some way to make the call to retrieve the storage_dir come after the auto generation of the uuid id?
Chris
The text was updated successfully, but these errors were encountered: