chore: remove misc. references to TextContent and FileContent

docs/decisions/0015-serving-static-assets.rst

@@ -18,7 +18,7 @@ Data Storage Implementation
 
 The underlying data models live in the openedx-learning repo. The most relevant models are:
 
-* `RawContent in contents/models.py <https://github.com/openedx/openedx-learning/blob/main/openedx_learning/core/contents/models.py>`_
+* `Content in contents/models.py <https://github.com/openedx/openedx-learning/blob/main/openedx_learning/core/contents/models.py>`_
 * `Component and ComponentVersion in components/models.py <https://github.com/openedx/openedx-learning/blob/main/openedx_learning/core/components/models.py>`_
 
 Key takeaways about how this data is stored:

olx_importer/management/commands/load_components.py

@@ -11,7 +11,7 @@
 
 Open Question: If the data model is extensible, how do we know whether a change
 has really happened between what's currently stored/published for a particular
-item and the new value we want to set? For RawContent that's easy, because we
+item and the new value we want to set? For Content that's easy, because we
 have actual hashes of the data. But it's not clear how that would work for
 something like an ComponentVersion. We'd have to have some kind of mechanism where every
 pp that wants to attach data gets to answer the question of "has anything
@@ -164,7 +164,7 @@ def import_block_type(self, block_type_name, now): # , publish_log_entry):
                 created_by=None,
             )
 
-            # Create the RawContent entry for the raw data...
+            # Create the Content entry for the raw data...
             text = xml_file_path.read_text('utf-8')
             text_content, _created = contents_api.get_or_create_text_content(
                 self.learning_package.id,

openedx_learning/contrib/media_server/readme.rst

@@ -1,7 +1,7 @@
 Media Server App
 ================
 
-The ``media_server`` app exists to serve media files that are ultimately backed by the RawContent model, *for development purposes and for sites with light-to-moderate traffic*. It also provides an API that can be used by CDNs for high traffic sites.
+The ``media_server`` app exists to serve media files that are ultimately backed by the Content model, *for development purposes and for sites with light-to-moderate traffic*. It also provides an API that can be used by CDNs for high traffic sites.
 
 Motivation
 ----------

openedx_learning/core/components/api.py

@@ -105,10 +105,10 @@ def create_next_version(
     A very common pattern for making a new ComponentVersion is going to be "make
     it just like the last version, except changing these one or two things".
     Before calling this, you should create any new contents via the contents
-    API, since ``content_to_replace`` needs RawContent IDs for the values.
+    API, since ``content_to_replace`` needs Content IDs for the values.
 
     The ``content_to_replace`` dict is a mapping of strings representing the
-    local path/key for a file, to ``RawContent.id`` values. Using a `None` for
+    local path/key for a file, to ``Content.id`` values. Using a `None` for
     a value in this dict means to delete that key in the next version.
 
     It is okay to mark entries for deletion that don't exist. For instance, if a
@@ -305,7 +305,7 @@ def get_component_version_content(
     Look up ComponentVersionContent by human readable keys.
 
     Can raise a django.core.exceptions.ObjectDoesNotExist error if there is no
-    matching ComponentVersionRawContent.
+    matching ComponentVersionContent.
     """
     queries = (
         Q(component_version__component__learning_package__key=learning_package_key)
@@ -317,7 +317,6 @@ def get_component_version_content(
                                   .select_related(
                                       "content",
                                       "content__media_type",
-                                      "content__textcontent",
                                       "component_version",
                                       "component_version__component",
                                       "component_version__component__learning_package",

openedx_learning/core/components/readme.rst

@@ -18,6 +18,6 @@ Architecture Guidelines
 
 * We're keeping nearly unlimited history, so per-version metadata (i.e. the space/time cost of making a new version) must be kept low.
 * Do not assume that all Components will be XBlocks.
-* Encourage other apps to make models that join to (and add their own metadata to) Component, ComponentVersion, RawContent, TextContent etc. But it should be done in such a way that this app is not aware of them.
+* Encourage other apps to make models that join to (and add their own metadata to) Component, ComponentVersion, Content, etc. But it should be done in such a way that this app is not aware of them.
 * Always preserve the most raw version of the data possible, e.g. OLX, even if XBlocks then extend that with more sophisticated data models. At some point those XBlocks will get deprecated/removed, and we will still want to be able to export the raw data.
 * Exports should be fast and *not* require the invocation of plugin code.

openedx_learning/core/contents/api.py

@@ -26,11 +26,6 @@ def get_or_create_media_type(mime_type: str) -> MediaType:
     the different XBlocks that will be installed in different server instances,
     each of which will use their own MediaType.
 
-    This will typically only be called when create_raw_content is calling it to
-    lookup the media_type_id it should use for a new RawContent. If you already
-    have a RawContent instance, it makes much more sense to access its
-    media_type relation.
-
     Caching Warning: Be careful about putting any caching decorator around this
     function (e.g. ``lru_cache``). It's possible that incorrect cache values
     could leak out in the event of a rollback–e.g. new types are introduced in

openedx_learning/core/contents/models.py

@@ -57,7 +57,7 @@ class MediaType(models.Model):
        "application/javascript". Also, we will be using a fair number of "vnd."
        style of custom content types, and we may want the flexibility of
        changing that without having to worry about migrating millions of rows of
-       RawContent.
+       Content.
     """
     # We're going to have many foreign key references from Content into this
     # model, and we don't need to store those as 8-byte BigAutoField, as is the
@@ -123,7 +123,7 @@ class Content(models.Model):
     least one of these methods, but can use both if it's appropriate.
 
     Use the ``text`` field when:
-    * the content is a relatively small (< 10K, often much less) piece of text
+    * the content is a relatively small (< 50K, usually much less) piece of text
     * you want to do be able to query up update across many rows at once
     * low, predictable latency is important
 
@@ -218,7 +218,9 @@ class Content(models.Model):
     )
 
     # This hash value may be calculated using create_hash_digest from the
-    # openedx.lib.fields module. Note that even TextContent needs to use this
+    # openedx.lib.fields module. When storing text, we hash the UTF-8
+    # encoding of that text value, regardless of whether we also write it to a
+    # file or not.
     hash_digest = hash_field()
 
     # Do we have file data stored for this Content in our file storage backend?