Recording pagination

[BryonLewis]

resolves #325

• Adds a copy_recordings management command that will take the existing recordings and create a new number of them efficiently by copying data instead of running the entire spectrogram generation. It also has the capability to add some random tags to test tagging and filtering.
  • Example manage.py copy_recordings --count 1000 --tags "foo,bar,test" should copy and create 1000 recordings with a mixure of tags being test foo and bar.
• Modifies the basic /recording endpoint to support vuetify v-data-table-server pagination system
  • tried to make the creation of the output more efficient by structuring and using prefetch for certain fields
• api.ts has been updated with the new request and return results for the /recording endpoint
• Submission Logic moved from Client to Server Side
  • a lot of useState.ts submission logic and computed values have been removed in favor of the get /recordings endpoint returning filtered data. Moving the filtering to the server instead of the client
• Added a new endpoint for getting the unsubmitted neighbors - /unsubmitted-neighbors. This will return the information for the previous and next buttons
• The Recording List uses a default sort and only returns the next 20 recordings. I don't know if we want a full v-data-table-server system or not to be used with this.
• When submitting a recording it re-retrieves the data so we don't need to mark it as complete locally using the emit system

[naglepuff]

I'm not sure if anything needs to change in particular, but I had some questions.

[naglepuff]

Was there an issue that this is helping to solve? I thought that the front end knew what to do if this endpoint 404'd. I wasn't expecting to see any changes to vetting details stuff in this PR

[BryonLewis]

I'll revert it. This is a hard one because we are using vetting/user/{user.id} where there should only be a single value per user, unlike anotherexample comment/{id} where there it is the intention of it to exist or not based on the Id.

Like if you had /vetting/user and it used the request authentication to determine the user_id I wouldn't want it to 404 if no value is set, it would just be an empty value indicating it hasn't been set yet. I viewed it not as a possible collection of data and more as

[naglepuff]

Is there a schema class we can use here instead of appending this dictionary?

[BryonLewis]

I created a Schema, while doing this I also updated a possible failure condition when using ArrayAgg for the tag text values.

[naglepuff]

Is tag_list ever None in this block?

[BryonLewis]

q.tags above this line is guarded so it isn't None:

 if q.tags and q.tags.strip():
        tag_list = [t.strip() for t in q.tags.split(',') if t.strip()]
        for tag in tag_list:
            queryset = queryset.filter(tags__text=tag)
        if tag_list:
            queryset = queryset.distinct()

So the tags used for the for_list will always be at least a string. It can be an empty string but even that will create an empty array for tag_list.

[naglepuff]

How does this work if the user is looking at either the first or last recording? Should we "wrap" around in those cases, or is that too much of a lift? I can see both cases