Fix internal links after documentation restructure

claude · claude · commit 46f362d542fc · 2025-12-23T02:37:46.000Z
Update all internal links to reflect new file locations:
- manipulation/ → operations/
- compute/ → operations/
- sysadmin/ → admin/
- Remove links to deleted theory pages (normalization, integrity, recall)
diff --git a/docs/src/admin/external-store.md b/docs/src/admin/external-store.md
@@ -34,7 +34,7 @@ For example, the following table stores motion-aligned two-photon movies.
 aligned_movie :  blob@external  # motion-aligned movie in 'external' store
 ```
 
-All [insert](../manipulation/insert.md) and [fetch](../query/fetch.md) operations work
+All [insert](../operations/insert.md) and [fetch](../query/fetch.md) operations work
 identically for `external` attributes as they do for `blob` attributes, with the same
 serialization protocol.
 Similar to `blobs`, `external` attributes cannot be used in restriction conditions.
@@ -116,12 +116,12 @@ configured external store.
 [foreign keys](../design/tables/dependencies.md) referencing the
 `~external_<storename>` table (but are not shown as such to the user).
 
-8. The [insert](../manipulation/insert.md) operation encodes and hashes the blob data.
+8. The [insert](../operations/insert.md) operation encodes and hashes the blob data.
 If an external object is not present in storage for the same hash, the object is saved
 and if the save operation is successful, corresponding entities in table
 `~external_<storename>` for that store are created.
 
-9. The [delete](../manipulation/delete.md)  operation first deletes the foreign key
+9. The [delete](../operations/delete.md) operation first deletes the foreign key
 reference in the target table. The external table entry and actual external object is
 not actually deleted at this time (`soft-delete`).
 
diff --git a/docs/src/client/settings.md b/docs/src/client/settings.md
@@ -152,7 +152,7 @@ dj.config.database.use_tls = None   # Auto (default)
 
 ## External Storage
 
-Configure external stores in the `stores` section. See [External Storage](../sysadmin/external-store.md) for details.
+Configure external stores in the `stores` section. See [External Storage](../admin/external-store.md) for details.
 
 ```json
 {
diff --git a/docs/src/datatypes/filepath.md b/docs/src/datatypes/filepath.md
@@ -16,7 +16,7 @@ tables to reference data which reside outside of DataJoint
 pipelines.
 
 To define a table using the `filepath` datatype, an existing DataJoint
-[store](../../sysadmin/external-store.md) should be created and then referenced in the
+[store](../admin/external-store.md) should be created and then referenced in the
 new table definition. For example, given a simple store:
 
 ```python
diff --git a/docs/src/design/tables/attributes.md b/docs/src/design/tables/attributes.md
@@ -53,7 +53,7 @@ fractional digits.
    Stores and returns raw bytes without serialization.
    For serialized Python objects (arrays, dicts, etc.), use `<djblob>` instead.
    The `longblob` and other `blob` datatypes can be configured to store data
-   [externally](../../sysadmin/external-store.md) by using the `blob@store` syntax.
+   [externally](../../admin/external-store.md) by using the `blob@store` syntax.
 
 ## Less common (but supported) datatypes
 
diff --git a/docs/src/design/tables/declare.md b/docs/src/design/tables/declare.md
@@ -216,7 +216,7 @@ Such attributes must be uniquely named in each table, such as `session_start_tim
 
 Secondary attributes can be given default values.
 A default value will be used for an attribute if no other value is given at the time
-the entity is [inserted](../../manipulation/insert.md) into the table.
+the entity is [inserted](../../operations/insert.md) into the table.
 Generally, default values are numerical values or character strings.
 Default values for dates must be given as strings as well, contained within quotes
 (with the exception of `CURRENT_TIMESTAMP`).
diff --git a/docs/src/design/tables/master-part.md b/docs/src/design/tables/master-part.md
@@ -68,7 +68,7 @@ directly.
 The only valid method to delete from a part table is to delete the master.
 This has been an unenforced rule, but upcoming versions of DataJoint will prohibit
 direct deletes from the master table.
-DataJoint's [delete](../../manipulation/delete.md) operation is also enclosed in a
+DataJoint's [delete](../../operations/delete.md) operation is also enclosed in a
 transaction.
 
 Together, the rules of master-part relationships ensure a key aspect of data integrity:
diff --git a/docs/src/design/tables/tiers.md b/docs/src/design/tables/tiers.md
@@ -26,7 +26,7 @@ superclass.
 Therefore, the corresponding User table on the database would be of the Manual tier.
 Furthermore, the classes for **imported** and **computed** tables have additional
 capabilities for automated processing as described in
-[Auto-populate](../../compute/populate.md).
+[Auto-populate](../../operations/populate.md).
 
 ## Internal conventions for naming tables
 
diff --git a/docs/src/operations/index.md b/docs/src/operations/index.md
@@ -5,5 +5,4 @@ without modifying the structure of the stored data.
 These operations include [insert](insert.md), [delete](delete.md), and
 [update](update.md).
 
-Data manipulation operations in DataJoint respect the
-[integrity](../design/integrity.md) constraints.
+Data manipulation operations in DataJoint respect integrity constraints.
diff --git a/docs/src/operations/make.md b/docs/src/operations/make.md
@@ -1,6 +1,6 @@
 # Transactions in Make
 
-Each call of the [make](../compute/make.md) method is enclosed in a transaction.
+Each call of the `make` method is enclosed in a transaction.
 DataJoint users do not need to explicitly manage transactions but must be aware of
 their use.
 
@@ -16,8 +16,7 @@ become visible to other processes until the `make` call completes execution.
 If the `make` method raises an exception, all changes made so far will be discarded and
 will never become visible to other processes.
 
-Transactions are particularly important in maintaining
-[group integrity](../design/integrity.md#group-integrity) with
+Transactions are particularly important in maintaining group integrity with
 [master-part relationships](../design/tables/master-part.md).
 The `make` call of a master table first inserts the master entity and then inserts all
 the matching part entities in the part tables.
diff --git a/docs/src/operations/populate.md b/docs/src/operations/populate.md
@@ -22,7 +22,7 @@ Their data definition follows the same [definition syntax](../design/tables/decl
 ## Make
 
 For auto-populated tables, data should never be entered using
-[insert](../manipulation/insert.md) directly.
+[insert](insert.md) directly.
 Instead these tables must define the callback method `make(self, key)`.
 The `insert` method then can only be called on `self` inside this callback method.
 
diff --git a/docs/src/operations/update.md b/docs/src/operations/update.md
@@ -3,18 +3,16 @@
 In database programming, the **update** operation refers to modifying the values of
 individual attributes in an entity within a table without replacing the entire entity.
 Such an in-place update mechanism is not part of DataJoint's data manipulation model,
-because it circumvents data
-[dependency constraints](../design/integrity.md#referential-integrity).
+because it circumvents data dependency constraints.
 
 This is not to say that data cannot be changed once they are part of a pipeline.
 In DataJoint, data is changed by replacing entire entities rather than by updating the
 values of their attributes.
 The process of deleting existing entities and inserting new entities with corrected
-values ensures the [integrity](../design/integrity.md) of the data throughout the
-pipeline.
+values ensures the integrity of the data throughout the pipeline.
 
 This approach applies specifically to automated tables
-(see [Auto-populated tables](../compute/populate.md)).
+(see [Auto-populated tables](populate.md)).
 However, manual tables are often edited outside DataJoint through other interfaces.
 It is up to the user's discretion to allow updates in manual tables, and the user must
 be cognizant of the fact that updates will not trigger re-computation of dependent data.
diff --git a/docs/src/query/operators.md b/docs/src/query/operators.md
@@ -33,7 +33,7 @@ languages to simplify and enhance the construction and interpretation of precise
 efficient data queries.
 
 1. **Entity integrity**: Data are represented and manipulated in the form of tables
-representing [well-formed entity sets](../design/integrity.md).
+representing well-formed entity sets.
    This applies to the inputs and outputs of query operators.
    The output of a query operator is an entity set with a well-defined entity type, a
    primary key, unique attribute names, etc.
@@ -155,8 +155,8 @@ and others.
 
 The result of the union operator `A + B` contains all the entities from both operands.
 
-[Entity normalization](../design/normalization) requires that `A` and `B` are of the same type,
-with with the same [primary key](../concepts/glossary#primary-key), using homologous
+Entity normalization requires that `A` and `B` are of the same type,
+with the same primary key, using homologous
 attributes. Without secondary attributes, the result is the simple set union. With
 secondary attributes, they must have the same names and datatypes. The two operands
 must also be **disjoint**, without any duplicate primary key values across both inputs.
diff --git a/docs/src/query/principles.md b/docs/src/query/principles.md
@@ -72,7 +72,7 @@ n = len(Session & 'session_date >= "2018-01-01"')
 
 ## Normalization in queries
 
-Query objects adhere to entity [entity normalization](../design/normalization.md) just
+Query objects adhere to entity normalization just
 like the stored tables do.
 The result of a query is a well-defined entity set with an readily identifiable entity
 class and designated primary attributes that jointly distinguish any two entities from
diff --git a/docs/src/query/restrict.md b/docs/src/query/restrict.md
@@ -178,7 +178,7 @@ is equivalent to `A - cond`.
 
 Restriction by a query object is a generalization of restriction by a table (which is
 also a query object), because DataJoint queries always produce well-defined entity
-sets, as described in  [entity normalization](../design/normalization.md).
+sets, as described in entity normalization.
 As such, restriction by queries follows the same behavior as restriction by tables
 described above.
 
diff --git a/docs/src/query/union.md b/docs/src/query/union.md
@@ -7,7 +7,7 @@ Union is rarely needed in practice.
 ## Union operator `+`
 
 The result of the union operator `A + B` contains all the entities from both operands.
-[Entity normalization](../design/normalization.md) requires that the operands in a
+Entity normalization requires that the operands in a
 union both belong to the same entity type with the same primary key using homologous
 attributes.
 In the absence of any secondary attributes, the result of a union is the simple set union.
diff --git a/docs/src/quick-start.md b/docs/src/quick-start.md
@@ -319,7 +319,7 @@ Area.populate(display_progress=True)
 ```
 
 The `make` method populates automated tables from inserted data. Read more in the
-full article [here](./compute/make.md)
+full article [here](./operations/make.md)
 
 ## Query
 

Original file line number	Diff line number	Diff line change
`@@ -152,7 +152,7 @@ dj.config.database.use_tls = None # Auto (default)`
`152`	`152`
`153`	`153`	`## External Storage`
`154`	`154`
`155`		-Configure external stores in the `stores` section. See [External Storage](../sysadmin/external-store.md) for details.
	`155`	+Configure external stores in the `stores` section. See [External Storage](../admin/external-store.md) for details.
`156`	`156`
`157`	`157`	```json
`158`	`158`	`{`