Merge pull request #2092 from MTG/vector-search-speedup

Remove old similarity code and improve speed of vector-search queries

Author: ffont

_docs/api/source/overview.rst

@@ -41,31 +41,22 @@ Searching
 =========
 
 There are several ways in which you can search sounds using the Freesound APIv2.
-The most basic one is using the :ref:`sound-text-search` resource which allows you to define some query terms and other parameters to filter query results.
+The most basic one is using the :ref:`sound-text-search` resource which allows you to define query terms and other parameters to filter query results.
 As a quick example, the following request would return all sorts of dog sounds:
 
 ::
 
-  curl "https://freesound.org/apiv2/search/text/?query=dogs&token=YOUR_API_KEY"
+  curl "https://freesound.org/apiv2/search/?query=dogs&token=YOUR_API_KEY"
 
 
-Besides text-search, you can also use the :ref:`sound-content-search` resource to perform queries and define filters based on audio features (descriptors) rather than tags and textual metadata.
+Search queries can include filters based on audio features (descriptors) rather than tags and textual metadata.
 That means that you can retrieve sounds that, for example, have a particular pitch or bpm. These queries may include almost any of the audio features listed in :ref:`analysis-docs`.
 Note however that these features are automatically extracted and might not be always accurate.
-As a quick example, you can retrieve sounds that feature a particular pitch mean as follows:
+As a quick example, you can retrieve sounds that feature a particular pitch as follows:
 
 ::
 
-  curl "https://freesound.org/apiv2/search/content/?descriptors_filter=lowlevel.pitch.mean:\[219.9%20TO%20220.1\]"
-
-
-Furthermore, you can combine both textual and content based search strategies using the :ref:`sound-combined-search` resource.
-This is useful as it allows you to specify a query or filter both in terms of metadata and audio features.
-For example, you could search for loops with a particular bpm using the following query:
-
-::
-
- curl "https://freesound.org/apiv2/search/combined/?filter=tag:loop&descriptors_filter=rhythm.bpm:\[119%20TO%20121\]"
+  curl "https://freesound.org/apiv2/search/?filter=pitch:\[219.9%20TO%20220.1\]"
 
 
 Downloading sounds

_docs/api/source/resources.rst

@@ -255,207 +255,6 @@ Examples
 {{examples_Search}}
 
 
-.. _sound-content-search:
-
-Content Search (deprecated)
-=========================================================
-
-::
-
-  GET /apiv2/search/content/
-  POST /apiv2/search/content/
-
-This resource allows searching sounds in Freesound based on their content descriptors.
-
-.. warning:: As of December 2023, this resource is deprecated and will be removed in the comming months. Similar functionality
-  will be achievable using the :ref:`sound-search` resource. Documentation about how to do this will be added in due time
-  but in the meantime, please contact us if you need help with this.
-
-.. _sound-content-search-parameters:
-
-Parameters (content search parameters)
-----------------------------------------------
-
-Content search queries are defined using the following request parameters:
-
-.. rst-class:: fieldstable
-=========================  =========================  ======================
-Name                       Type                       Description
-=========================  =========================  ======================
-target                     string or numeric           This parameter defines a target based on content-based descriptors to sort the search results. It can be set as a number of descriptor name and value pairs, or as a sound id. See below.
-analysis_file              file                       **Experimental** - Alternatively, targets can be specified by uploading a file with the output of the Essentia Freesound Extractor analysis of any sound that you analyzed locally (see below). This parameter overrides ``target``, and requires the use of POST method.
-descriptors_filter         string                     This parameter allows filtering query results by values of the content-based descriptors. See below for more information.
-=========================  =========================  ======================
-
-**The 'target' and 'analysis_file' parameters**
-
-The ``target`` parameter can be used to specify a content-based sorting of your search results.
-Using ``target`` you can sort the query results so that the first results will be the sounds featuring the most similar descriptors to the given target.
-To specify a target you must use a syntax like ``target=descriptor_name:value``.
-You can also set multiple descriptor/value pairs in a target separating them with spaces (``target=descriptor_name:value descriptor_name:value``).
-Descriptor names must be chosen from those listed in :ref:`analysis-docs`.  
-Only numerical descriptors are allowed.
-Multidimensional descriptors with fixed-length (that always have the same number of dimensions) are allowed too (see below).
-Consider the following two ``target`` examples::
-
-  (A) target=lowlevel.pitch.mean:220
-  (B) target=lowlevel.pitch.mean:220 lowlevel.pitch.var:0
-
-Example A will sort the query results so that the first results will have a mean pitch as close to 220Hz as possible.
-Example B will sort the query results so that the first results will have a mean pitch as close to 220Hz as possible and a pitch variance as close as possible to 0.
-In that case example B will promote sounds that have a steady pitch close to 220Hz.
-
-Multidimensional descriptors can also be used in the ``target`` parameter::
-
-  target=sfx.tristimulus.mean:0,1,0
-
-Alternatively, ``target`` can also be set to point to a Freesound sound.
-In that case the descriptors of the sound will be used as the target for the query, therefore query results will be sorted according to their similarity to the targeted sound.
-To set a sound as a target of the query you must use the sound id. For example, to use sound with id 1234 as target::
-
-  target=1234
-
-
-There is even another way to specify a target for the query, which is by uploading an analysis file generated using the Essentia Freesound Extractor.
-For doing that you will need to download and compile Essentia (we recommend using release 2.0.1), an open source feature extraction library developed at the Music Technology Group (https://github.com/mtg/essentia/tree/2.0.1),
-and use the 'streaming_extractor_freesound' example to analyze any sound you have in your local computer.
-As a result, the extractor will create a JSON file that you can use as target in your Freesound API content search queries.
-To use this file as target you will need to use the POST method (instead of GET) and attach the file as an ``analysis_file`` POST parameter (see example below).
-Setting the target as an ``analysis_file`` allows you to to find sounds in Freesound that are similar to any other sound that you have in your local computer and that it is not part of Freesound.
-When using ``analysis_file``, the contents of ``target`` are ignored. Note that **this feature is experimental**. Some users reported not being able to generate compatible analysis files.
-
-Note that if ``target`` (or ``analysis_file``) is not used in combination with ``descriptors_filter``, the results of the query will
-include all sounds from Freesound indexed in the similarity server, sorted by similarity to the target.
-
-
-**The 'descriptors_filter' parameter**
-
-The ``descriptors_filter`` parameter is used to restrict the query results to those sounds whose content descriptor values match with the defined filter.
-To define ``descriptors_filter`` parameter you can use the same syntax as for the normal ``filter`` parameter, including numeric ranges and simple logic operators.
-For example, ``descriptors_filter=lowlevel.pitch.mean:220`` will only return sounds that have an EXACT pitch mean of 220hz.
-Note that this would probably return no results as a sound will rarely have that exact pitch (might be very close like 219.999 or 220.000001 but not exactly 220).
-For this reason, in general it might be better to indicate ``descriptors_filter`` using ranges.
-Descriptor names must be chosen from those listed in :ref:`analysis-docs`.
-Note that most of the descriptors provide several statistics (var, mean, min, max...). In that case, the descriptor name must include also the desired statistic (see examples below).
-Non fixed-length descriptors are not allowed.
-Some examples of ``descriptors_filter`` for numerical descriptors::
-
-  descriptors_filter=lowlevel.pitch.mean:[219.9 TO 220.1]
-  descriptors_filter=lowlevel.pitch.mean:[219.9 TO 220.1] AND lowlevel.pitch_salience.mean:[0.6 TO *]
-  descriptors_filter=lowlevel.mfcc.mean[0]:[-1124 TO -1121]
-  descriptors_filter=lowlevel.mfcc.mean[1]:[17 TO 20] AND lowlevel.mfcc.mean[4]:[0 TO 20]
-
-Note how in the last two examples the filter operates in a particular dimension of a multidimensional descriptor (with dimension index starting at 0).
-
-``descriptors_filter`` can also be defined using non numerical descriptors such as 'tonal.key_key' or 'tonal.key_scale'.
-In that case, the value must be enclosed in double quotes '"', and the character '#' (for example for an A# key) must be indicated with the string 'sharp'.
-Non numerical descriptors can not be indicated using ranges.
-For example::
-
-  descriptors_filter=tonal.key_key:"Asharp"
-  descriptors_filter=tonal.key_scale:"major"
-  descriptors_filter=(tonal.key_key:"C" AND tonal.key_scale:"major") OR (tonal.key_key:"A" AND tonal.key_scale:"minor")
-
-You can combine both numerical and non numerical descriptors as well::
-
-  descriptors_filter=tonal.key_key:"C" tonal.key_scale="major" tonal.key_strength:[0.8 TO *]
-
-
-Response
---------
-
-The Content Search resource returns a sound list just like :ref:`sound-list-response`.
-The same extra request parameters apply (``page``, ``page_size``, ``fields``, ``descriptors`` and ``normalized``).
-
-
-Examples
---------
-
-{{examples_ContentSearch}}
-
-
-.. _sound-combined-search:
-
-Combined Search (deprecated)
-=========================================================
-
-::
-
-  GET /apiv2/search/combined/
-  POST /apiv2/search/combined/
-
-This resource is a combination of :ref:`sound-search` and :ref:`sound-content-search`, and allows searching sounds in Freesound based on their tags, metadata and content-based descriptors.
-
-.. warning:: As of December 2023, this resource is deprecated and will be removed in the comming months. Similar functionality
-  will be achievable using the :ref:`sound-search` resource. Documentation about how to do this will be added in due time
-  but in the meantime, please contact us if you need help with this.
-
-Parameters
-------------------
-
-Combined Search request parameters can include any of the parameters from text-based search queries (``query``, ``filter`` and ``sort``, :ref:`sound-search-parameters`)
-and content-based search queries (``target``, ``analysis_file`` and ``descriptors_filter`` and, :ref:`sound-content-search-parameters`).
-Note that ``group_by_pack`` **is not** available in combined search queries.
-
-In Combined Search, queries can be defined both like a standard textual query or as a target of content-descriptors, and
-query results can be filtered by values of sounds' metadata and sounds' content-descriptors... all at once!
-
-To perform a Combined Search query you must at least specify a ``query`` or a ``target`` parameter (as you would do in text-based and content-based searches respectively),
-and at least one text-based or content-based filter (``filter`` and ``descriptors_filter``).
-Request parameters ``query`` and ``target`` can not be used at the same time, but ``filter`` and ``descriptors_filter`` can both be present in a single Combined Search query.
-In any case, you must always use at least one text-based search request parameter and one content-based search request parameter.
-Note that ``sort`` parameter must always be accompanied by a ``query`` or ``filter`` parameter (or both), otherwise it is ignored.
-``sort`` parameter will also be ignored if parameter ``target`` (or ``analysis_file``) is present in the query.
-
-Combined Search requests might **require significant computational resources** on our servers depending on the particular
-query that is made. Therefore, responses might take longer than usual. Fortunately, response times can vary a lot
-with some small modifications in the query, and this is in your hands ;).
-As a general rule, we recommend not to use the text-search parameter ``query``, and instead define metadata stuff in a ``filter``.
-For example, instead of setting the parameter ``query=loop``, try filtering results to sounds that have the tag loop (``filter=tag:loop``).
-Furthermore, you can try narrowing down your filter or filters (``filter`` and ``descriptors_filter``) and possibly make the queries faster.
-Best response times are normally obtained by specifying a content-based ``target`` in combination with text-based and
-content-based filters (``filter`` and ``descriptors_filter``).
-
-
-Response
---------
-
-The Combined Search resource **returns a variation** of the standard sound list response :ref:`sound-list-response`.
-Combined Search responses are dictionaries with the following structure:
-
-::
-
-  {
-    "results": [
-        <sound result #1 info>,
-        <sound result #2 info>,
-        ...
-    ],
-    "more": <link to get more results (null if there are no more results)>,
-  }
-
-The ``results`` field will include a list of sounds just like in the normal sound list response.
-The length of this list can be defined using the ``page_size`` request parameter like in normal sound list responses.
-However, Combined Search responses **do not guarantee** that the number of elements inside ``results`` will be equal to
-the number specified in ``page_size``. In some cases, you might find less results, so **you should verify the length of the list**.
-
-Furthermore, instead of the ``next`` and ``previous`` links to navigate among results, Combined Search responses
-only offer a ``more`` link that you can use to obtain more results. You can think of the ``more`` link as a
-rough equivalent to ``next``, but it does not work by indicating page numbers as in normal sound list responses.
-
-Also, note that ``count`` field is not present in the Combined Search response, therefore you do not know in advance the total
-amount of results that a query can return.
-
-Finally, Combined Search responses does allow you to use the ``fields``, ``descriptors`` and ``normalized``
-parameters just like you would do in standard sound list responses.
-
-
-Examples
---------
-
-{{examples_CombinedSearch}}
-
-
 Sound resources
 >>>>>>>>>>>>>>>
 

accounts/tests/test_profile.py

@@ -673,9 +673,8 @@ def setUp(self):
             num_sounds=3, num_packs=3, processing_state="OK", moderation_state="OK"
         )
 
-    @mock.patch("sounds.models.delete_sound_from_gaia")
     @mock.patch("sounds.models.delete_sounds_from_search_engine")
-    def test_download_sound_count_field_is_updated(self, delete_sounds_from_search_engine, delete_sound_from_gaia):
+    def test_download_sound_count_field_is_updated(self, delete_sounds_from_search_engine):
         # Test downloading sounds increases the "num_sound_downloads" field
         for i in range(len(self.sounds)):
             Download.objects.create(user=self.user, sound=self.sounds[i], license_id=self.sounds[i].license_id)

accounts/tests/test_user.py

@@ -306,9 +306,8 @@ def test_user_delete_keep_sounds(self):
         self.assertTrue(Sound.objects.filter(user__id=user.id).exists())
         self.assertTrue(Sound.objects.filter(user__id=user.id)[0].is_index_dirty)
 
-    @mock.patch("sounds.models.delete_sound_from_gaia")
     @mock.patch("sounds.models.delete_sounds_from_search_engine")
-    def test_user_delete_include_sounds(self, delete_sounds_from_search_engine, delete_sound_from_gaia):
+    def test_user_delete_include_sounds(self, delete_sounds_from_search_engine):
         # This should set user's attribute deleted_user to True and anonymize it
         # Sounds and Packs should be deleted (creating DeletedSound objects), but other user content should be preserved
         user = self.create_user_and_content()
@@ -334,11 +333,9 @@ def test_user_delete_include_sounds(self, delete_sounds_from_search_engine, dele
         self.assertTrue(DeletedSound.objects.filter(user__id=user.id).exists())
 
         delete_sounds_from_search_engine.assert_has_calls([mock.call([i]) for i in user_sound_ids], any_order=True)
-        delete_sound_from_gaia.assert_has_calls([mock.call(i) for i in user_sound_ids], any_order=True)
 
-    @mock.patch("sounds.models.delete_sound_from_gaia")
     @mock.patch("sounds.models.delete_sounds_from_search_engine")
-    def test_user_delete_sounds_and_user_object(self, delete_sounds_from_search_engine, delete_sound_from_gaia):
+    def test_user_delete_sounds_and_user_object(self, delete_sounds_from_search_engine):
         # This should delete all user content, including the User object, and create a DeletedUser object. This will
         # create DeletedSound objects.
         user = self.create_user_and_content()
@@ -357,12 +354,10 @@ def test_user_delete_sounds_and_user_object(self, delete_sounds_from_search_engi
         self.assertFalse(OldUsername.objects.filter(user__id=user.id).exists())
 
         delete_sounds_from_search_engine.assert_has_calls([mock.call([i]) for i in user_sound_ids], any_order=True)
-        delete_sound_from_gaia.assert_has_calls([mock.call(i) for i in user_sound_ids], any_order=True)
 
     @skipIf(True, "This tests a method that should never be called")
-    @mock.patch("sounds.models.delete_sound_from_gaia")
     @mock.patch("sounds.models.delete_sounds_from_search_engine")
-    def test_user_full_delete(self, delete_sounds_from_search_engine, delete_sound_from_gaia):
+    def test_user_full_delete(self, delete_sounds_from_search_engine):
         # This should delete all user content, including the User object and without creating DeletedUser. It does
         # create however DeletedSound objects.
         user = self.create_user_and_content()
@@ -386,7 +381,6 @@ def test_user_full_delete(self, delete_sounds_from_search_engine, delete_sound_f
 
         calls = [mock.call(i) for i in user_sound_ids]
         delete_sounds_from_search_engine.assert_has_calls(calls, any_order=True)
-        delete_sound_from_gaia.assert_has_calls(calls, any_order=True)
 
     @mock.patch("general.tasks.delete_user.delay")
     def test_user_delete_include_sounds_using_web_form(self, submit_job):
@@ -506,11 +500,10 @@ def test_delete_user_reasons(self):
             user.profile.delete_user(deletion_reason=reason)
             self.assertEqual(DeletedUser.objects.get(user_id=user.id).reason, reason)
 
-    @mock.patch("sounds.models.delete_sound_from_gaia")
     @mock.patch("sounds.models.delete_sounds_from_search_engine")
     @mock.patch("forum.models.delete_posts_from_search_engine")
     def test_delete_user_with_count_fields_out_of_sync(
-        self, delete_posts_from_search_engine, delete_sounds_from_search_engine, delete_sound_from_gaia
+        self, delete_posts_from_search_engine, delete_sounds_from_search_engine
     ):
         # Test that deleting a user work properly even when the profile count fields (num_sounds, num_posts,
         # num_sound_downloads and num_pack_downloads) are out of sync. This is a potential issue because if the