|Subject:||Re: [GMG-Devel] Tags/Collections for batchaddmedia|
|Date:||Mon, 9 Nov 2015 00:16:57 -0800|
I'm a bit delayed because I wanted to successfully upload my latest vacation, which required video transcoding, which requires Debian Jessie, which required something something yak hair.Anyway that's all done; I will try my best to get the patch done tonight after my other Sunday to-dos. However one edge case came to mind as I had the transcoding errors, and I'm wondering about your opinion. Supposing a user were to try to batchaddmedia a cvs's worth of stuff, and come upon an error. They fix it (maybe they just had to apt-get more gstreamer stuff). At that point, they shouldn't just re-run the command, they should edit the csv to remove the items they already successfully uploaded (that's what I did). Maybe I could just put a warning message to do so if there's an error?What would be worse, though, is if they chose to use celery to process things. Processing errors (video or otherwise) would be silent, and the other files would proceed anyway. Not such a big deal in general, but with collections it's an issue because order tends to matter (from a user perspective). They can't just fix the processing problem, go back, and re-upload the ones they missed. Even if we added re-ordering features, it loses some of the benefit of "bulk" to have to move things around manually after the fact. So, perhaps I should disable, or at least give a y/n warning, for batchaddmedia with celery, if there are any collections specified in the file?Thanks.On Fri, Nov 6, 2015 at 6:45 AM, Dan Krol <address@hidden> wrote:Oh that's right I can just make a temporary hacking installation. I'll do that.On Fri, Nov 6, 2015 at 5:30 AM, Christopher Allan Webber <address@hidden> wrote:It's prooooobably safe :)
Jessica just landed some major database changes (and now is taking a
month long break to avoid total burnout, it was a big task).
As a warning, there are some failing tests that I need to address, which
I just found yesterday.
It depends how critical things currently are. You may wish to either
copy the database over for local hacking and testing and delay your main
update... or if some bugs are okay, go ahead and upgrade, and make a
I'm going to try to get all tests passing again early next week.
Dan Krol writes:
> Hopefully this weekend. Should I be safe to upgrade to the current HEAD of
> master and migrate my database? (I make backups between upgrades
> On Wed, Nov 4, 2015 at 8:38 AM, Christopher Allan Webber <
> address@hidden> wrote:
>> That would be great. We might release a 0.8.1 very shortly. maybe we
>> can make it in for that?
>> Of course, that's up to what you have time for!
>> Dan Krol writes:
>> > Great, thanks. I'm assuming I'd want to make it based on master rather
>> > v0.8.0? It looks like the db schema related to collections has changed.
>> > On Tue, Nov 3, 2015 at 2:40 PM, Christopher Allan Webber <
>> > address@hidden> wrote:
>> >> Awesome, thanks for the patch!
>> >> Dan Krol writes:
>> >> > Okay, I'm guessing that the reason tags weren't added to
>> batchaddmedia is
>> >> > that submit_media takes a string parameter for tag names rather than
>> >> > corresponding tag objects. This means that submit_media would likely
>> >> > querying for the same tags over and over again, which is very
>> >> inefficient.
>> >> > So, it's maybe worth splitting out a function underneath submit_media
>> >> that
>> >> > takes the tag objects, which submit_media calls on? Do you all have a
>> >> > recommended way to do this, that's in line with your code's
>> >> organization? I
>> >> > assume just adding tag_objects and collection_objects parameters would
>> >> > muddy up submit_media's interface.
>> >> I think that should be possible. We could just add another keyword
>> >> argument to submit_media that takes tag objects.
>> >> > For my own purposes I can just do it the inefficient way for now, if
>> >> > there's not a great answer for this. Here's what it looks like at the
>> >> > moment (forked from v0.8.0 fo rnow), and it seems to work:
>> >> >
>> >> Yay!
>> >> If you wanted to do the more efficient route, I'd quite happily accept a
>> >> patch/branch and merge it.
|[Prev in Thread]||Current Thread||[Next in Thread]|