cocoindex 0.1.51__tar.gz → 0.1.52__tar.gz

{cocoindex-0.1.51 → cocoindex-0.1.52}/Cargo.lock

@@ -1040,7 +1040,7 @@ dependencies = [
 
 [[package]]
 name = "cocoindex"
-version = "0.1.51"
+version = "0.1.52"
 dependencies = [
  "anyhow",
  "async-openai",

{cocoindex-0.1.51 → cocoindex-0.1.52}/Cargo.toml

@@ -2,7 +2,7 @@
 name = "cocoindex"
 # Version used for local development is always higher than others to take precedence.
 # Will be overridden for specific release versions.
-version = "0.1.51"
+version = "0.1.52"
 edition = "2024"
 rust-version = "1.86"
 

{cocoindex-0.1.51 → cocoindex-0.1.52}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cocoindex
-Version: 0.1.51
+Version: 0.1.52
 Requires-Dist: sentence-transformers>=3.3.1
 Requires-Dist: click>=8.1.8
 Requires-Dist: rich>=14.0.0
@@ -130,7 +130,7 @@ def text_embedding_flow(flow_builder: cocoindex.FlowBuilder, data_scope: cocoind
     # Export collected data to a vector index.
     doc_embeddings.export(
         "doc_embeddings",
-        cocoindex.storages.Postgres(),
+        cocoindex.targets.Postgres(),
         primary_key_fields=["filename", "location"],
         vector_indexes=[
             cocoindex.VectorIndexDef(

{cocoindex-0.1.51 → cocoindex-0.1.52}/README.md

@@ -111,7 +111,7 @@ def text_embedding_flow(flow_builder: cocoindex.FlowBuilder, data_scope: cocoind
     # Export collected data to a vector index.
     doc_embeddings.export(
         "doc_embeddings",
-        cocoindex.storages.Postgres(),
+        cocoindex.targets.Postgres(),
         primary_key_fields=["filename", "location"],
         vector_indexes=[
             cocoindex.VectorIndexDef(

{cocoindex-0.1.51 → cocoindex-0.1.52}/docs/docs/core/basics.md

@@ -9,7 +9,7 @@ An **index** is a collection of data stored in a way that is easy for retrieval.
 
 CocoIndex is an ETL framework for building indexes from specified data sources, a.k.a. **indexing**. It also offers utilities for users to retrieve data from the indexes.
 
-An **indexing flow** extracts data from specified data sources, upon specified transformations, and puts the transformed data into specified storage for later retrieval.
+An **indexing flow** extracts data from specified data sources, upon specified transformations, and puts the transformed data into specified target for later retrieval.
 
 ## Indexing flow elements
 
@@ -17,7 +17,7 @@ An indexing flow has two aspects: data and operations on data.
 
 ### Data
 
-An indexing flow involves source data and transformed data (either as an intermediate result or the final result to be put into storage). All data within the indexing flow has **schema** determined at flow definition time.
+An indexing flow involves source data and transformed data (either as an intermediate result or the final result to be put into targets). All data within the indexing flow has **schema** determined at flow definition time.
 
 Each piece of data has a **data type**, falling into one of the following categories:
 
@@ -36,8 +36,8 @@ An **operation** in an indexing flow defines a step in the flow. An operation is
 *   **Action**, which defines the behavior of the operation, e.g. *import*, *transform*, *for each*, *collect* and *export*.
     See [Flow Definition](flow_def) for more details for each action.
 
-*   Some actions (i.e. "import", "transform" and "export") require an **Operation Spec**, which describes the specific behavior of the operation, e.g. a source to import from, a function describing the transformation behavior, a target storage to export to (as an index).
-    *   Each operation spec has a **operation type**, e.g. `LocalFile` (data source), `SplitRecursively` (function), `SentenceTransformerEmbed` (function), `Postgres` (storage).
+*   Some actions (i.e. "import", "transform" and "export") require an **Operation Spec**, which describes the specific behavior of the operation, e.g. a source to import from, a function describing the transformation behavior, a target to export to (as an index).
+    *   Each operation spec has a **operation type**, e.g. `LocalFile` (data source), `SplitRecursively` (function), `SentenceTransformerEmbed` (function), `Postgres` (target).
     *   CocoIndex framework maintains a set of supported operation types. Users can also implement their own.
 
 "import" and "transform" operations produce output data, whose data type is determined based on the operation spec and data types of input data (for "transform" operation only).
@@ -62,11 +62,11 @@ This shows schema and example data for the indexing flow:
 
 ## Life cycle of an indexing flow
 
-An indexing flow, once set up, maintains a long-lived relationship between data source and data in target storage. This means:
+An indexing flow, once set up, maintains a long-lived relationship between data source and target. This means:
 
-1.  The target storage created by the flow remain available for querying at any time
+1.  The target created by the flow remain available for querying at any time
 
-2.  As source data changes (new data added, existing data updated or deleted), data in the target storage are updated to reflect those changes,
+2.  As source data changes (new data added, existing data updated or deleted), data in the target are updated to reflect those changes,
     on certain pace, according to the update mode:
 
     *   **One time update**: Once triggered, CocoIndex updates the target data to reflect the version of source data up to the current moment.

{cocoindex-0.1.51 → cocoindex-0.1.52}/docs/docs/core/cli.mdx

@@ -61,7 +61,7 @@ The following subcommands are available:
 | ---------- | ----------- |
 | `ls` | List all flows present in the given file/module. Or list all persisted flows under the current app namespace if no file/module specified. |
 | `show` | Show the spec and schema for a specific flow. |
-| `setup` | Check and apply backend setup changes for flows, including the internal and target storage (to export). |
+| `setup` | Check and apply backend setup changes for flows, including the internal storage and target (to export). |
 | `drop` | Drop the backend setup for specified flows. |
 | `update` | Update the index defined by the flow. |
 | `evaluate` | Evaluate the flow and dump flow outputs to files.  Instead of updating the index, it dumps what should be indexed to files. Mainly used for evaluation purpose. |

{cocoindex-0.1.51 → cocoindex-0.1.52}/docs/docs/core/data_types.mdx

@@ -13,7 +13,7 @@ This makes schema of data processed by CocoIndex clear, and easily determine the
 
 You don't need to spell out data types in CocoIndex, when you define the flow using existing operations (source, function, etc).
 These operations decide data types of fields produced by them based on the spec and input data types.
-All you need to do is to make sure the data passed to functions and storage targets are accepted by them.
+All you need to do is to make sure the data passed to functions and targets are accepted by them.
 
 When you define [custom functions](/docs/core/custom_function), you need to specify the data types of arguments and return values.
 
@@ -40,7 +40,7 @@ This is the list of all basic types supported by CocoIndex:
 | Vector[*T*, *Dim*?] | *T* can be a basic type or a numeric type. *Dim* is a positive integer and optional. | `cocoindex.Vector[T]` or `cocoindex.Vector[T, Dim]` | `numpy.typing.NDArray[T]` or `list[T]` |
 
 Values of all data types can be represented by values in Python's native types (as described under the Native Python Type column).
-However, the underlying execution engine and some storage system (like Postgres) has finer distinctions for some types, specifically:
+However, the underlying execution engine has finer distinctions for some types, specifically:
 
 *   *Float32* and *Float64* for `float`, with different precision.
 *   *LocalDateTime* and *OffsetDateTime* for `datetime.datetime`, with different timezone awareness.
@@ -50,7 +50,7 @@ However, the underlying execution engine and some storage system (like Postgres)
 
 The native Python type is always more permissive and can represent a superset of possible values.
 *   Only when you annotate the return type of a custom function, you should use the specific type,
-    so that CocoIndex will have information about the precise type to be used in the execution engine and storage system.
+    so that CocoIndex will have information about the precise type to be used in the execution engine and target.
 *   For all other purposes, e.g. to provide annotation for argument types of a custom function, or used internally in your custom function,
     you can choose whatever to use.
     The native Python type is usually simpler.

{cocoindex-0.1.51 → cocoindex-0.1.52}/docs/docs/core/flow_def.mdx

@@ -1,6 +1,6 @@
 ---
 title: Flow Definition
-description: Define a CocoIndex flow, by specifying source, transformations and storages, and connect input/output data of them.
+description: Define a CocoIndex flow, by specifying source, transformations and targets, and connect input/output data of them.
 ---
 
 import Tabs from '@theme/Tabs';
@@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem';
 
 # CocoIndex Flow Definition
 
-In CocoIndex, to define an indexing flow, you provide a function to import source, transform data and put them into target storage (sinks).
+In CocoIndex, to define an indexing flow, you provide a function to import source, transform data and put them into targets.
 You connect input/output of these operations with fields of data scopes.
 
 ## Entry Point
@@ -246,14 +246,14 @@ and generates a `id` field with UUID and remains stable when `filename` and `sum
 
 ### Export
 
-The `export()` method exports the collected data to an external storage.
+The `export()` method exports the collected data to an external target.
 
-A *storage spec* needs to be provided for any export operation, to describe the storage and parameters related to the storage.
+A *target spec* needs to be provided for any export operation, to describe the target and parameters related to the target.
 
 Export must happen at the top level of a flow, i.e. not within any child scopes created by "for each row". It takes the following arguments:
 
 *   `name`: the name to identify the export target.
-*   `target_spec`: the storage spec as the export target.
+*   `target_spec`: the target spec as the export target.
 *   `setup_by_user` (optional):
      whether the export target is setup by user.
      By default, CocoIndex is managing the target setup (surfaced by the `cocoindex setup` CLI subcommand), e.g. create related tables/collections/etc. with compatible schema, and update them upon change.
@@ -270,7 +270,7 @@ def demo_flow(flow_builder: cocoindex.FlowBuilder, data_scope: cocoindex.DataSco
     demo_collector = data_scope.add_collector()
     ...
     demo_collector.export(
-        "demo_storage", DemoStorageSpec(...),
+        "demo_target", DemoTargetSpec(...),
         primary_key_fields=["field1"],
         vector_indexes=[cocoindex.VectorIndexDef("field2", cocoindex.VectorSimilarityMetric.COSINE_SIMILARITY)])
 ```
@@ -278,14 +278,14 @@ def demo_flow(flow_builder: cocoindex.FlowBuilder, data_scope: cocoindex.DataSco
 </TabItem>
 </Tabs>
 
-The target storage is managed by CocoIndex, i.e. it'll be created by [CocoIndex CLI](/docs/core/cli) when you run `cocoindex setup`, and the data will be automatically updated (including stale data removal) when updating the index.
-The `name` for the same storage should remain stable across different runs.
-If it changes, CocoIndex will treat it as an old storage removed and a new one created, and perform setup changes and reindexing accordingly.
+The target is managed by CocoIndex, i.e. it'll be created by [CocoIndex CLI](/docs/core/cli) when you run `cocoindex setup`, and the data will be automatically updated (including stale data removal) when updating the index.
+The `name` for the same target should remain stable across different runs.
+If it changes, CocoIndex will treat it as an old target removed and a new one created, and perform setup changes and reindexing accordingly.
 
 ## Storage Indexes
 
-Many storage supports indexes, to boost efficiency in retrieving data.
-CocoIndex provides a common way to configure indexes for various storages.
+Many targets are storage systems supporting indexes, to boost efficiency in retrieving data.
+CocoIndex provides a common way to configure indexes for various targets.
 
 ### Primary Key
 
@@ -330,7 +330,7 @@ For example,
 ```python
 doc_embeddings.export(
     "doc_embeddings",
-    cocoindex.storages.Qdrant(
+    cocoindex.targets.Qdrant(
         collection_name=cocoindex.get_app_namespace(trailing_delimiter='__') + "doc_embeddings",
         ...
     ),
@@ -345,8 +345,8 @@ It will use `Staging__doc_embeddings` as the collection name if the current app
 
 ### Target Declarations
 
-Most time a target storage is created by calling `export()` method on a collector, and this `export()` call comes with configurations needed for the target storage, e.g. options for storage indexes.
-Occasionally, you may need to specify some configurations for target storage out of the context of any specific data collector.
+Most time a target is created by calling `export()` method on a collector, and this `export()` call comes with configurations needed for the target, e.g. options for storage indexes.
+Occasionally, you may need to specify some configurations for the target out of the context of any specific data collector.
 
 For example, for graph database targets like `Neo4j` and `Kuzu`, you may have a data collector to export data to relationships, which will create nodes referenced by various relationships in turn.
 These nodes don't directly come from any specific data collector (consider relationships from different data collectors may share the same nodes).
@@ -359,7 +359,7 @@ To specify configurations for these nodes, you can *declare* spec for related no
 
 ```python
 flow_builder.declare(
-    cocoindex.storages.Neo4jDeclarations(...)
+    cocoindex.targets.Neo4jDeclarations(...)
 )
 ```
 
@@ -389,7 +389,7 @@ You can add an auth entry by `cocoindex.add_auth_entry()` function, which return
 ```python
 my_graph_conn = cocoindex.add_auth_entry(
     "my_graph_conn",
-    cocoindex.storages.Neo4jConnectionSpec(
+    cocoindex.targets.Neo4jConnectionSpec(
             uri="bolt://localhost:7687",
             user="neo4j",
             password="cocoindex",
@@ -403,7 +403,7 @@ Then reference it when building a spec that takes an auth entry:
     ```python
     demo_collector.export(
         "MyGraph",
-        cocoindex.storages.Neo4jRelationship(connection=my_graph_conn, ...)
+        cocoindex.targets.Neo4jRelationship(connection=my_graph_conn, ...)
     )
     ```
 
@@ -412,7 +412,7 @@ Then reference it when building a spec that takes an auth entry:
     ```python
     demo_collector.export(
         "MyGraph",
-        cocoindex.storages.Neo4jRelationship(connection=cocoindex.ref_auth_entry("my_graph_conn"), ...))
+        cocoindex.targets.Neo4jRelationship(connection=cocoindex.ref_auth_entry("my_graph_conn"), ...))
     ```
 
 </TabItem>

{cocoindex-0.1.51 → cocoindex-0.1.52}/docs/docs/core/flow_methods.mdx

@@ -1,7 +1,7 @@
 ---
 title: Run a Flow
 toc_max_heading_level: 4
-description: Run a CocoIndex Flow, including build / update data in the target storage and evaluate the flow without changing the target storage.
+description: Run a CocoIndex Flow, including build / update data in the target and evaluate the flow without changing the target.
 ---
 
 import Tabs from '@theme/Tabs';
@@ -37,7 +37,7 @@ It creates a `demo_flow` object in `cocoindex.Flow` type.
 
 ## Build / update target data
 
-The major goal of a flow is to perform the transformations on source data and build / update data in the target storage (the index).
+The major goal of a flow is to perform the transformations on source data and build / update data in the target.
 This action has two modes:
 
 *   **One time update.**
@@ -53,7 +53,7 @@ This action has two modes:
 :::info
 
 For both modes, CocoIndex is performing *incremental processing*,
-i.e. we only perform computations and storage mutations on source data that are changed, or the flow has changed.
+i.e. we only perform computations and target mutations on source data that are changed, or the flow has changed.
 This is to achieve best efficiency.
 
 :::
@@ -63,7 +63,7 @@ This is to achieve best efficiency.
 
 #### CLI
 
-The `cocoindex update` subcommand creates/updates data in the target storage.
+The `cocoindex update` subcommand creates/updates data in the target.
 
 Once it's done, the target data is fresh up to the moment when the function is called.
 
@@ -76,7 +76,7 @@ cocoindex update main.py
 <Tabs>
 <TabItem value="python" label="Python">
 
-The `update()` async method creates/updates data in the target storage.
+The `update()` async method creates/updates data in the target.
 
 Once the function returns, the target data is fresh up to the moment when the function is called.
 
@@ -207,7 +207,7 @@ CocoIndex also provides asynchronous versions of APIs for blocking operations, i
 
 ## Evaluate the flow
 
-CocoIndex allows you to run the transformations defined by the flow without updating the target storage.
+CocoIndex allows you to run the transformations defined by the flow without updating the target.
 
 ### CLI
 

{cocoindex-0.1.51 → cocoindex-0.1.52}/docs/docs/getting_started/quickstart.md

@@ -87,7 +87,7 @@ def text_embedding_flow(flow_builder: cocoindex.FlowBuilder, data_scope: cocoind
     # Export collected data to a vector index.
     doc_embeddings.export(
         "doc_embeddings",
-        cocoindex.storages.Postgres(),
+        cocoindex.targets.Postgres(),
         primary_key_fields=["filename", "location"],
         vector_indexes=[
             cocoindex.VectorIndexDef(
@@ -214,7 +214,7 @@ from pgvector.psycopg import register_vector
 
 def search(pool: ConnectionPool, query: str, top_k: int = 5):
     # Get the table name, for the export target in the text_embedding_flow above.
-    table_name = cocoindex.utils.get_target_storage_default_name(text_embedding_flow, "doc_embeddings")
+    table_name = cocoindex.utils.get_target_default_name(text_embedding_flow, "doc_embeddings")
     # Evaluate the transform flow defined above with the input query, to get the embedding.
     query_vector = text_to_embedding.eval(query)
     # Run the query and get the results.
@@ -237,7 +237,7 @@ There're two CocoIndex-specific logic:
 1.  Get the table name from the export target in the `text_embedding_flow` above.
     Since the table name for the `Postgres` target is not explicitly specified in the `export()` call,
     CocoIndex uses a default name.
-    `cocoindex.utils.get_target_storage_default_name()` is a utility function to get the default table name for this case.
+    `cocoindex.utils.get_target_default_name()` is a utility function to get the default table name for this case.
 
 2.  Evaluate the transform flow defined above with the input query, to get the embedding.
     It's done by the `eval()` method of the transform flow `text_to_embedding`.

cocoindex-0.1.51/docs/docs/ops/storages.md → cocoindex-0.1.52/docs/docs/ops/targets.md

@@ -1,17 +1,17 @@
 ---
-title: Storages
-description: CocoIndex Built-in Storages
+title: Targets
+description: CocoIndex Built-in Targets
 toc_max_heading_level: 4
 ---
 
-# CocoIndex Built-in Storages
+# CocoIndex Built-in Targets
 
-For each target storage, data are exported from a data collector, containing data of multiple entries, each with multiple fields.
-The way to map data from a data collector to a target storage depends on data model of the target storage.
+For each target, data are exported from a data collector, containing data of multiple entries, each with multiple fields.
+The way to map data from a data collector to a target depends on data model of the target.
 
 ## Entry-Oriented Targets
 
-Entry-Oriented Storage organizes data into independent entries, such as rows, key-value pairs, or documents.
+An entry-oriented target organizes data into independent entries, such as rows, key-value pairs, or documents.
 Each entry is self-contained and does not explicitly link to others.
 There is usually a straightforward mapping from data collector rows to entries.
 
@@ -113,7 +113,7 @@ Here's how CocoIndex data elements map to nodes in the graph:
 
 Note that the label used in different `Nodes`s should be unique.
 
-`cocoindex.storages.Nodes` is to describe mapping to nodes. It has the following fields:
+`cocoindex.targets.Nodes` is to describe mapping to nodes. It has the following fields:
 
 *   `label` (type: `str`): The label of the node.
 
@@ -133,9 +133,9 @@ We can export them to nodes under label `Document` like this:
 ```python
 document_collector.export(
     ...
-    cocoindex.storages.Neo4j(
+    cocoindex.targets.Neo4j(
         ...
-        mapping=cocoindex.storages.Nodes(label="Document"),
+        mapping=cocoindex.targets.Nodes(label="Document"),
     ),
     primary_key_fields=["filename"],
 )
@@ -168,7 +168,7 @@ graph TD
 
 If a node label needs to appear as source or target of a relationship, but not exported as a node, you need to [declare](../core/flow_def#target-declarations) the label with necessary configuration.
 
-The dataclass to describe the declaration is specific to each target storage (e.g. `cocoindex.storages.Neo4jDeclarations`),
+The dataclass to describe the declaration is specific to each target (e.g. `cocoindex.targets.Neo4jDeclarations`),
 while they share the following common fields:
 
 *   `nodes_label` (required): The label of the node.
@@ -181,7 +181,7 @@ Considering we want to extract relationships from `Document` to `Place` later (i
 
 ```python
 flow_builder.declare(
-    cocoindex.storages.Neo4jDeclarations(
+    cocoindex.targets.Neo4jDeclarations(
         connection = ...,
         nodes_label="Place",
         primary_key_fields=["name"],
@@ -201,12 +201,12 @@ Here's how CocoIndex data elements map to relationships in the graph:
 
 Note that the type used in different `Relationships`s should be unique.
 
-`cocoindex.storages.Relationships` is to describe mapping to relationships. It has the following fields:
+`cocoindex.targets.Relationships` is to describe mapping to relationships. It has the following fields:
 
 *   `rel_type` (type: `str`): The type of the relationship.
-*   `source`/`target` (type: `cocoindex.storages.NodeFromFields`): Specify how to extract source/target node information from specific fields in the collected row. It has the following fields:
+*   `source`/`target` (type: `cocoindex.targets.NodeFromFields`): Specify how to extract source/target node information from specific fields in the collected row. It has the following fields:
     *   `label` (type: `str`): The label of the node.
-    *   `fields` (type: `Sequence[cocoindex.storages.TargetFieldMapping]`): Specify field mappings from the collected rows to node properties, with the following fields:
+    *   `fields` (type: `Sequence[cocoindex.targets.TargetFieldMapping]`): Specify field mappings from the collected rows to node properties, with the following fields:
         *   `source` (type: `str`): The name of the field in the collected row.
         *   `target` (type: `str`, optional): The name of the field to use as the node field. If unspecified, will use the same as `source`.
 
@@ -238,19 +238,19 @@ We can export them to relationships under type `MENTION` like this:
 ```python
 doc_place_collector.export(
     ...
-    cocoindex.storages.Neo4j(
+    cocoindex.targets.Neo4j(
         ...
-        mapping=cocoindex.storages.Relationships(
+        mapping=cocoindex.targets.Relationships(
             rel_type="MENTION",
-            source=cocoindex.storages.NodeFromFields(
+            source=cocoindex.targets.NodeFromFields(
                 label="Document",
-                fields=[cocoindex.storages.TargetFieldMapping(source="doc_filename", target="filename")],
+                fields=[cocoindex.targets.TargetFieldMapping(source="doc_filename", target="filename")],
             ),
-            target=cocoindex.storages.NodeFromFields(
+            target=cocoindex.targets.NodeFromFields(
                 label="Place",
                 fields=[
-                    cocoindex.storages.TargetFieldMapping(source="place_name", target="name"),
-                    cocoindex.storages.TargetFieldMapping(source="place_embedding", target="embedding"),
+                    cocoindex.targets.TargetFieldMapping(source="place_name", target="name"),
+                    cocoindex.targets.TargetFieldMapping(source="place_embedding", target="embedding"),
                 ],
             ),
         ),

{cocoindex-0.1.51 → cocoindex-0.1.52}/docs/docs/query.mdx

@@ -80,7 +80,7 @@ print(await text_to_embedding.eval_async("Hello, world!"))
 
 In your indexing flow, when you export data to a target, you can specify the target name (e.g. a database table name, a collection name, the node label in property graph databases, etc.) explicitly,
 or for some backends you can also omit it and let CocoIndex generate a default name for you.
-For the latter case, CocoIndex provides a utility function `cocoindex.utils.get_target_storage_default_name()` to get the default name.
+For the latter case, CocoIndex provides a utility function `cocoindex.utils.get_target_default_name()` to get the default name.
 It takes the following arguments:
 
 *   `flow` (type: `cocoindex.Flow`): The flow to get the default name for.
@@ -92,7 +92,7 @@ For example:
 <TabItem value="python" label="Python">
 
 ```python
-table_name = cocoindex.utils.get_target_storage_default_name(text_embedding_flow, "doc_embeddings")
+table_name = cocoindex.utils.get_target_default_name(text_embedding_flow, "doc_embeddings")
 query = f"SELECT filename, text FROM {table_name} ORDER BY embedding <=> %s DESC LIMIT 5"
 ...
 ```

{cocoindex-0.1.51 → cocoindex-0.1.52}/docs/docusaurus.config.ts

@@ -57,6 +57,10 @@ const config: Config = {
             from: '/core/initialization',
             to: '/core/settings',
           },
+          {
+            from: '/ops/storages',
+            to: '/ops/targets',
+          },
         ],
       },
     ],

{cocoindex-0.1.51 → cocoindex-0.1.52}/docs/sidebars.ts

@@ -33,7 +33,7 @@ const sidebars: SidebarsConfig = {
       items: [
         'ops/sources',
         'ops/functions',
-        'ops/storages',
+        'ops/targets',
       ],
     },
     {

{cocoindex-0.1.51 → cocoindex-0.1.52}/python/cocoindex/__init__.py

@@ -2,7 +2,9 @@
 Cocoindex is a framework for building and running indexing pipelines.
 """
 
-from . import functions, sources, storages, cli, utils
+from . import functions, sources, targets, cli, utils
+
+from . import targets as storages  # Deprecated: Use targets instead
 
 from .auth_registry import AuthEntryReference, add_auth_entry, ref_auth_entry
 from .flow import FlowBuilder, DataScope, DataSlice, Flow, transform_flow
@@ -21,6 +23,7 @@ __all__ = [
     "_engine",
     "functions",
     "sources",
+    "targets",
     "storages",
     "cli",
     "utils",

{cocoindex-0.1.51 → cocoindex-0.1.52}/python/cocoindex/cli.py

@@ -247,8 +247,7 @@ def show(app_flow_specifier: str, color: bool, verbose: bool) -> None:
 )
 def setup(app_target: str, force: bool) -> None:
     """
-    Check and apply backend setup changes for flows, including the internal and target storage
-    (to export).
+    Check and apply backend setup changes for flows, including the internal storage and target (to export to).
 
     APP_TARGET: path/to/app.py or installed_module.
     """

{cocoindex-0.1.51 → cocoindex-0.1.52}/python/cocoindex/flow.py

@@ -327,7 +327,7 @@ class DataCollector:
     def export(
         self,
         name: str,
-        target_spec: op.StorageSpec,
+        target_spec: op.TargetSpec,
         /,
         *,
         primary_key_fields: Sequence[str],
@@ -340,7 +340,7 @@ class DataCollector:
 
         `vector_index` is for backward compatibility only. Please use `vector_indexes` instead.
         """
-        if not isinstance(target_spec, op.StorageSpec):
+        if not isinstance(target_spec, op.TargetSpec):
             raise ValueError(
                 "export() can only be called on a CocoIndex target storage"
             )

{cocoindex-0.1.51 → cocoindex-0.1.52}/python/cocoindex/op.py

@@ -19,7 +19,7 @@ class OpCategory(Enum):
 
     FUNCTION = "function"
     SOURCE = "source"
-    STORAGE = "storage"
+    TARGET = "target"
     DECLARATION = "declaration"
 
 
@@ -52,8 +52,8 @@ class FunctionSpec(metaclass=SpecMeta, category=OpCategory.FUNCTION):  # pylint:
     """A function spec. All its subclass can be instantiated similar to a dataclass, i.e. ClassName(field1=value1, field2=value2, ...)"""
 
 
-class StorageSpec(metaclass=SpecMeta, category=OpCategory.STORAGE):  # pylint: disable=too-few-public-methods
-    """A storage spec. All its subclass can be instantiated similar to a dataclass, i.e. ClassName(field1=value1, field2=value2, ...)"""
+class TargetSpec(metaclass=SpecMeta, category=OpCategory.TARGET):  # pylint: disable=too-few-public-methods
+    """A target spec. All its subclass can be instantiated similar to a dataclass, i.e. ClassName(field1=value1, field2=value2, ...)"""
 
 
 class DeclarationSpec(metaclass=SpecMeta, category=OpCategory.DECLARATION):  # pylint: disable=too-few-public-methods

cocoindex-0.1.51/python/cocoindex/storages.py → cocoindex-0.1.52/python/cocoindex/targets.py

@@ -1,4 +1,4 @@
-"""All builtin storages."""
+"""All builtin targets."""
 
 from dataclasses import dataclass
 from typing import Sequence
@@ -9,8 +9,8 @@ from .auth_registry import AuthEntryReference
 from .setting import DatabaseConnectionSpec
 
 
-class Postgres(op.StorageSpec):
-    """Storage powered by Postgres and pgvector."""
+class Postgres(op.TargetSpec):
+    """Target powered by Postgres and pgvector."""
 
     database: AuthEntryReference[DatabaseConnectionSpec] | None = None
     table_name: str | None = None
@@ -25,8 +25,8 @@ class QdrantConnection:
 
 
 @dataclass
-class Qdrant(op.StorageSpec):
-    """Storage powered by Qdrant - https://qdrant.tech/."""
+class Qdrant(op.TargetSpec):
+    """Target powered by Qdrant - https://qdrant.tech/."""
 
     collection_name: str
     connection: AuthEntryReference[QdrantConnection] | None = None
@@ -52,7 +52,7 @@ class NodeFromFields:
 
 @dataclass
 class ReferencedNode:
-    """Storage spec for a graph node."""
+    """Target spec for a graph node."""
 
     label: str
     primary_key_fields: Sequence[str]
@@ -95,7 +95,7 @@ class Neo4jConnection:
     db: str | None = None
 
 
-class Neo4j(op.StorageSpec):
+class Neo4j(op.TargetSpec):
     """Graph storage powered by Neo4j."""
 
     connection: AuthEntryReference[Neo4jConnection]
@@ -119,7 +119,7 @@ class KuzuConnection:
     api_server_url: str
 
 
-class Kuzu(op.StorageSpec):
+class Kuzu(op.TargetSpec):
     """Graph storage powered by Kuzu."""
 
     connection: AuthEntryReference[KuzuConnection]

cocoindex-0.1.52/python/cocoindex/utils.py

@@ -0,0 +1,20 @@
+from .flow import Flow
+from .setting import get_app_namespace
+
+
+def get_target_default_name(flow: Flow, target_name: str, delimiter: str = "__") -> str:
+    """
+    Get the default name for a target.
+    It's used as the underlying target name (e.g. a table, a collection, etc.) followed by most targets, if not explicitly specified.
+    """
+    return (
+        get_app_namespace(trailing_delimiter=delimiter)
+        + flow.name
+        + delimiter
+        + target_name
+    )
+
+
+get_target_storage_default_name = (
+    get_target_default_name  # Deprecated: Use get_target_default_name instead
+)

{cocoindex-0.1.51 → cocoindex-0.1.52}/src/ops/mod.rs

@@ -5,7 +5,7 @@ pub mod registry;
 mod factory_bases;
 mod functions;
 mod sources;
-mod storages;
+mod targets;
 
 mod registration;
 pub(crate) use registration::*;