2023-08-18 14:57:18 +00:00
|
|
|
import pytest
|
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
2023-09-24 08:11:07 +00:00
|
|
|
from pydantic import TypeAdapter
|
2023-09-11 13:57:41 +00:00
|
|
|
|
2023-09-04 09:16:44 +00:00
|
|
|
from invokeai.app.invocations.baseinvocation import (
|
|
|
|
|
BaseInvocation,
|
|
|
|
|
BaseInvocationOutput,
|
|
|
|
|
InvalidVersionError,
|
|
|
|
|
invocation,
|
|
|
|
|
invocation_output,
|
|
|
|
|
)
|
2023-10-17 06:23:10 +00:00
|
|
|
from invokeai.app.invocations.primitives import (
|
|
|
|
|
FloatCollectionInvocation,
|
|
|
|
|
FloatInvocation,
|
|
|
|
|
IntegerInvocation,
|
|
|
|
|
StringInvocation,
|
|
|
|
|
)
|
2023-09-11 13:57:41 +00:00
|
|
|
from invokeai.app.invocations.upscale import ESRGANInvocation
|
feat: refactor services folder/module structure
Refactor services folder/module structure.
**Motivation**
While working on our services I've repeatedly encountered circular imports and a general lack of clarity regarding where to put things. The structure introduced goes a long way towards resolving those issues, setting us up for a clean structure going forward.
**Services**
Services are now in their own folder with a few files:
- `services/{service_name}/__init__.py`: init as needed, mostly empty now
- `services/{service_name}/{service_name}_base.py`: the base class for the service
- `services/{service_name}/{service_name}_{impl_type}.py`: the default concrete implementation of the service - typically one of `sqlite`, `default`, or `memory`
- `services/{service_name}/{service_name}_common.py`: any common items - models, exceptions, utilities, etc
Though it's a bit verbose to have the service name both as the folder name and the prefix for files, I found it is _extremely_ confusing to have all of the base classes just be named `base.py`. So, at the cost of some verbosity when importing things, I've included the service name in the filename.
There are some minor logic changes. For example, in `InvocationProcessor`, instead of assigning the model manager service to a variable to be used later in the file, the service is used directly via the `Invoker`.
**Shared**
Things that are used across disparate services are in `services/shared/`:
- `default_graphs.py`: previously in `services/`
- `graphs.py`: previously in `services/`
- `paginatation`: generic pagination models used in a few services
- `sqlite`: the `SqliteDatabase` class, other sqlite-specific things
2023-09-24 08:11:07 +00:00
|
|
|
from invokeai.app.services.shared.graph import (
|
2023-08-18 14:57:18 +00:00
|
|
|
CollectInvocation,
|
|
|
|
|
Edge,
|
|
|
|
|
EdgeConnection,
|
|
|
|
|
Graph,
|
|
|
|
|
InvalidEdgeError,
|
|
|
|
|
IterateInvocation,
|
|
|
|
|
NodeAlreadyInGraphError,
|
|
|
|
|
NodeNotFoundError,
|
|
|
|
|
are_connections_compatible,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
from .test_nodes import (
|
2023-10-17 06:23:10 +00:00
|
|
|
AnyTypeTestInvocation,
|
2023-08-18 14:57:18 +00:00
|
|
|
ImageToImageTestInvocation,
|
|
|
|
|
ListPassThroughInvocation,
|
2023-10-17 06:23:10 +00:00
|
|
|
PolymorphicStringTestInvocation,
|
|
|
|
|
PromptCollectionTestInvocation,
|
2023-08-18 14:57:18 +00:00
|
|
|
PromptTestInvocation,
|
|
|
|
|
TextToImageTestInvocation,
|
|
|
|
|
)
|
2022-12-01 05:33:20 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
# Helpers
|
2023-03-15 06:09:30 +00:00
|
|
|
def create_edge(from_id: str, from_field: str, to_id: str, to_field: str) -> Edge:
|
|
|
|
|
return Edge(
|
|
|
|
|
source=EdgeConnection(node_id=from_id, field=from_field),
|
|
|
|
|
destination=EdgeConnection(node_id=to_id, field=to_field),
|
|
|
|
|
)
|
2022-12-01 05:33:20 +00:00
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
# Tests
|
|
|
|
|
def test_connections_are_compatible():
|
2023-06-29 06:01:17 +00:00
|
|
|
from_node = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
from_field = "image"
|
2023-07-18 23:45:26 +00:00
|
|
|
to_node = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
to_field = "image"
|
|
|
|
|
|
|
|
|
|
result = are_connections_compatible(from_node, from_field, to_node, to_field)
|
|
|
|
|
|
2023-08-17 22:45:25 +00:00
|
|
|
assert result is True
|
2022-12-01 05:33:20 +00:00
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_connections_are_incompatible():
|
2023-06-29 06:01:17 +00:00
|
|
|
from_node = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
from_field = "image"
|
2023-07-18 23:45:26 +00:00
|
|
|
to_node = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
to_field = "strength"
|
|
|
|
|
|
|
|
|
|
result = are_connections_compatible(from_node, from_field, to_node, to_field)
|
|
|
|
|
|
2023-08-17 22:45:25 +00:00
|
|
|
assert result is False
|
2022-12-01 05:33:20 +00:00
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_connections_incompatible_with_invalid_fields():
|
2023-06-29 06:01:17 +00:00
|
|
|
from_node = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
from_field = "invalid_field"
|
2023-07-18 23:45:26 +00:00
|
|
|
to_node = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
to_field = "image"
|
|
|
|
|
|
|
|
|
|
# From field is invalid
|
|
|
|
|
result = are_connections_compatible(from_node, from_field, to_node, to_field)
|
2023-08-17 22:45:25 +00:00
|
|
|
assert result is False
|
2022-12-01 05:33:20 +00:00
|
|
|
|
|
|
|
|
# To field is invalid
|
|
|
|
|
from_field = "image"
|
|
|
|
|
to_field = "invalid_field"
|
|
|
|
|
|
|
|
|
|
result = are_connections_compatible(from_node, from_field, to_node, to_field)
|
2023-08-17 22:45:25 +00:00
|
|
|
assert result is False
|
2022-12-01 05:33:20 +00:00
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_can_add_node():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n)
|
|
|
|
|
|
|
|
|
|
assert n.id in g.nodes
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_fails_to_add_node_with_duplicate_id():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n)
|
2023-06-29 06:01:17 +00:00
|
|
|
n2 = TextToImageTestInvocation(id="1", prompt="Banana sushi the second")
|
2022-12-01 05:33:20 +00:00
|
|
|
|
|
|
|
|
with pytest.raises(NodeAlreadyInGraphError):
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_updates_node():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n)
|
2023-06-29 06:01:17 +00:00
|
|
|
n2 = TextToImageTestInvocation(id="2", prompt="Banana sushi the second")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n2)
|
|
|
|
|
|
2023-06-29 06:01:17 +00:00
|
|
|
nu = TextToImageTestInvocation(id="1", prompt="Banana sushi updated")
|
2022-12-01 05:33:20 +00:00
|
|
|
|
|
|
|
|
g.update_node("1", nu)
|
|
|
|
|
|
|
|
|
|
assert g.nodes["1"].prompt == "Banana sushi updated"
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_fails_to_update_node_if_type_changes():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n)
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n2)
|
|
|
|
|
|
2023-07-18 23:45:26 +00:00
|
|
|
nu = ESRGANInvocation(id="1")
|
2022-12-01 05:33:20 +00:00
|
|
|
|
|
|
|
|
with pytest.raises(TypeError):
|
|
|
|
|
g.update_node("1", nu)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_allows_non_conflicting_id_change():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n)
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n2)
|
|
|
|
|
e1 = create_edge(n.id, "image", n2.id, "image")
|
|
|
|
|
g.add_edge(e1)
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2023-06-29 06:01:17 +00:00
|
|
|
nu = TextToImageTestInvocation(id="3", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.update_node("1", nu)
|
|
|
|
|
|
|
|
|
|
with pytest.raises(NodeNotFoundError):
|
|
|
|
|
g.get_node("1")
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
assert g.get_node("3").prompt == "Banana sushi"
|
|
|
|
|
|
|
|
|
|
assert len(g.edges) == 1
|
2023-03-15 06:09:30 +00:00
|
|
|
assert (
|
|
|
|
|
Edge(source=EdgeConnection(node_id="3", field="image"), destination=EdgeConnection(node_id="2", field="image"))
|
|
|
|
|
in g.edges
|
2023-07-27 14:54:01 +00:00
|
|
|
)
|
|
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
|
|
|
|
|
def test_graph_fails_to_update_node_id_if_conflict():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n)
|
2023-06-29 06:01:17 +00:00
|
|
|
n2 = TextToImageTestInvocation(id="2", prompt="Banana sushi the second")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n2)
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2023-06-29 06:01:17 +00:00
|
|
|
nu = TextToImageTestInvocation(id="2", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
with pytest.raises(NodeAlreadyInGraphError):
|
|
|
|
|
g.update_node("1", nu)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_adds_edge():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "image", n2.id, "image")
|
|
|
|
|
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
|
|
|
|
assert e in g.edges
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_fails_to_add_edge_with_cycle():
|
|
|
|
|
g = Graph()
|
2023-07-18 23:45:26 +00:00
|
|
|
n1 = ESRGANInvocation(id="1")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
e = create_edge(n1.id, "image", n1.id, "image")
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_fails_to_add_edge_with_long_cycle():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
|
|
|
|
n3 = ESRGANInvocation(id="3")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
e1 = create_edge(n1.id, "image", n2.id, "image")
|
|
|
|
|
e2 = create_edge(n2.id, "image", n3.id, "image")
|
|
|
|
|
e3 = create_edge(n3.id, "image", n2.id, "image")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e3)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_fails_to_add_edge_with_missing_node_id():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e1 = create_edge("1", "image", "3", "image")
|
|
|
|
|
e2 = create_edge("3", "image", "1", "image")
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_fails_to_add_edge_when_destination_exists():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
|
|
|
|
n3 = ESRGANInvocation(id="3")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
e1 = create_edge(n1.id, "image", n2.id, "image")
|
|
|
|
|
e2 = create_edge(n1.id, "image", n3.id, "image")
|
|
|
|
|
e3 = create_edge(n2.id, "image", n3.id, "image")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_graph_fails_to_add_edge_with_mismatched_types():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e1 = create_edge("1", "image", "2", "strength")
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_connects_collector():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
|
|
|
|
n2 = TextToImageTestInvocation(id="2", prompt="Banana sushi 2")
|
2022-12-01 05:33:20 +00:00
|
|
|
n3 = CollectInvocation(id="3")
|
|
|
|
|
n4 = ListPassThroughInvocation(id="4")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
g.add_node(n4)
|
|
|
|
|
|
|
|
|
|
e1 = create_edge("1", "image", "3", "item")
|
|
|
|
|
e2 = create_edge("2", "image", "3", "item")
|
|
|
|
|
e3 = create_edge("3", "collection", "4", "collection")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
g.add_edge(e3)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
# TODO: test that derived types mixed with base types are compatible
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_collector_invalid_with_varying_input_types():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
n2 = PromptTestInvocation(id="2", prompt="banana sushi 2")
|
|
|
|
|
n3 = CollectInvocation(id="3")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
|
|
|
|
|
e1 = create_edge("1", "image", "3", "item")
|
|
|
|
|
e2 = create_edge("2", "prompt", "3", "item")
|
|
|
|
|
g.add_edge(e1)
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_collector_invalid_with_varying_input_output():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = PromptTestInvocation(id="1", prompt="Banana sushi")
|
|
|
|
|
n2 = PromptTestInvocation(id="2", prompt="Banana sushi 2")
|
|
|
|
|
n3 = CollectInvocation(id="3")
|
|
|
|
|
n4 = ListPassThroughInvocation(id="4")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
g.add_node(n4)
|
|
|
|
|
|
|
|
|
|
e1 = create_edge("1", "prompt", "3", "item")
|
|
|
|
|
e2 = create_edge("2", "prompt", "3", "item")
|
|
|
|
|
e3 = create_edge("3", "collection", "4", "collection")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e3)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_collector_invalid_with_non_list_output():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = PromptTestInvocation(id="1", prompt="Banana sushi")
|
|
|
|
|
n2 = PromptTestInvocation(id="2", prompt="Banana sushi 2")
|
|
|
|
|
n3 = CollectInvocation(id="3")
|
|
|
|
|
n4 = PromptTestInvocation(id="4")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
g.add_node(n4)
|
|
|
|
|
|
|
|
|
|
e1 = create_edge("1", "prompt", "3", "item")
|
|
|
|
|
e2 = create_edge("2", "prompt", "3", "item")
|
|
|
|
|
e3 = create_edge("3", "collection", "4", "prompt")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e3)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_connects_iterator():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = ListPassThroughInvocation(id="1")
|
|
|
|
|
n2 = IterateInvocation(id="2")
|
2023-06-29 06:01:17 +00:00
|
|
|
n3 = ImageToImageTestInvocation(id="3", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
|
|
|
|
|
e1 = create_edge("1", "collection", "2", "collection")
|
|
|
|
|
e2 = create_edge("2", "item", "3", "image")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
# TODO: TEST INVALID ITERATOR SCENARIOS
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_iterator_invalid_if_multiple_inputs():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = ListPassThroughInvocation(id="1")
|
|
|
|
|
n2 = IterateInvocation(id="2")
|
2023-06-29 06:01:17 +00:00
|
|
|
n3 = ImageToImageTestInvocation(id="3", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
n4 = ListPassThroughInvocation(id="4")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
g.add_node(n4)
|
|
|
|
|
|
|
|
|
|
e1 = create_edge("1", "collection", "2", "collection")
|
|
|
|
|
e2 = create_edge("2", "item", "3", "image")
|
|
|
|
|
e3 = create_edge("4", "collection", "2", "collection")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e3)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_iterator_invalid_if_input_not_list():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
n2 = IterateInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
|
|
|
|
|
e1 = create_edge("1", "collection", "2", "collection")
|
|
|
|
|
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_iterator_invalid_if_output_and_input_types_different():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = ListPassThroughInvocation(id="1")
|
|
|
|
|
n2 = IterateInvocation(id="2")
|
|
|
|
|
n3 = PromptTestInvocation(id="3", prompt="Banana sushi")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
|
|
|
|
|
e1 = create_edge("1", "collection", "2", "collection")
|
|
|
|
|
e2 = create_edge("2", "item", "3", "prompt")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_validates():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e1 = create_edge("1", "image", "2", "image")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
|
2023-08-17 22:45:25 +00:00
|
|
|
assert g.is_valid() is True
|
2022-12-01 05:33:20 +00:00
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_invalid_if_edges_reference_missing_nodes():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.nodes[n1.id] = n1
|
|
|
|
|
e1 = create_edge("1", "image", "2", "image")
|
|
|
|
|
g.edges.append(e1)
|
|
|
|
|
|
2023-08-17 22:45:25 +00:00
|
|
|
assert g.is_valid() is False
|
2022-12-01 05:33:20 +00:00
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_invalid_if_has_cycle():
|
|
|
|
|
g = Graph()
|
2023-07-18 23:45:26 +00:00
|
|
|
n1 = ESRGANInvocation(id="1")
|
|
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.nodes[n1.id] = n1
|
|
|
|
|
g.nodes[n2.id] = n2
|
|
|
|
|
e1 = create_edge("1", "image", "2", "image")
|
|
|
|
|
e2 = create_edge("2", "image", "1", "image")
|
|
|
|
|
g.edges.append(e1)
|
|
|
|
|
g.edges.append(e2)
|
|
|
|
|
|
2023-08-17 22:45:25 +00:00
|
|
|
assert g.is_valid() is False
|
2022-12-01 05:33:20 +00:00
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_invalid_with_invalid_connection():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.nodes[n1.id] = n1
|
|
|
|
|
g.nodes[n2.id] = n2
|
|
|
|
|
e1 = create_edge("1", "image", "2", "strength")
|
|
|
|
|
g.edges.append(e1)
|
|
|
|
|
|
2023-08-17 22:45:25 +00:00
|
|
|
assert g.is_valid() is False
|
2022-12-01 05:33:20 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_graph_gets_networkx_graph():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "image", n2.id, "image")
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
|
|
|
|
nxg = g.nx_graph()
|
|
|
|
|
|
|
|
|
|
assert "1" in nxg.nodes
|
|
|
|
|
assert "2" in nxg.nodes
|
|
|
|
|
assert ("1", "2") in nxg.edges
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# TODO: Graph serializes and deserializes
|
|
|
|
|
def test_graph_can_serialize():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
2023-07-18 23:45:26 +00:00
|
|
|
n2 = ESRGANInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "image", n2.id, "image")
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
|
|
|
|
# Not throwing on this line is sufficient
|
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
2023-09-24 08:11:07 +00:00
|
|
|
_ = g.model_dump_json()
|
2022-12-01 05:33:20 +00:00
|
|
|
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_can_deserialize():
|
|
|
|
|
g = Graph()
|
2023-06-29 06:01:17 +00:00
|
|
|
n1 = TextToImageTestInvocation(id="1", prompt="Banana sushi")
|
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
2023-09-24 08:11:07 +00:00
|
|
|
n2 = ImageToImageTestInvocation(id="2")
|
2022-12-01 05:33:20 +00:00
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "image", n2.id, "image")
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
2023-09-24 08:11:07 +00:00
|
|
|
json = g.model_dump_json()
|
2023-10-17 08:46:37 +00:00
|
|
|
GraphValidator = TypeAdapter(Graph)
|
|
|
|
|
g2 = GraphValidator.validate_json(json)
|
2022-12-01 05:33:20 +00:00
|
|
|
|
|
|
|
|
assert g2 is not None
|
|
|
|
|
assert g2.nodes["1"] is not None
|
|
|
|
|
assert g2.nodes["2"] is not None
|
|
|
|
|
assert len(g2.edges) == 1
|
2023-03-15 06:09:30 +00:00
|
|
|
assert g2.edges[0].source.node_id == "1"
|
|
|
|
|
assert g2.edges[0].source.field == "image"
|
|
|
|
|
assert g2.edges[0].destination.node_id == "2"
|
|
|
|
|
assert g2.edges[0].destination.field == "image"
|
2023-07-27 14:54:01 +00:00
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
|
2023-09-04 09:07:41 +00:00
|
|
|
def test_invocation_decorator():
|
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
2023-09-24 08:11:07 +00:00
|
|
|
invocation_type = "test_invocation_decorator"
|
2023-09-04 09:07:41 +00:00
|
|
|
title = "Test Invocation"
|
|
|
|
|
tags = ["first", "second", "third"]
|
|
|
|
|
category = "category"
|
2023-09-04 09:16:44 +00:00
|
|
|
version = "1.2.3"
|
2023-09-04 09:07:41 +00:00
|
|
|
|
2023-09-04 09:16:44 +00:00
|
|
|
@invocation(invocation_type, title=title, tags=tags, category=category, version=version)
|
|
|
|
|
class TestInvocation(BaseInvocation):
|
2023-09-04 09:07:41 +00:00
|
|
|
def invoke(self):
|
|
|
|
|
pass
|
|
|
|
|
|
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
2023-09-24 08:11:07 +00:00
|
|
|
schema = TestInvocation.model_json_schema()
|
2023-09-04 09:07:41 +00:00
|
|
|
|
|
|
|
|
assert schema.get("title") == title
|
|
|
|
|
assert schema.get("tags") == tags
|
|
|
|
|
assert schema.get("category") == category
|
2023-09-04 09:16:44 +00:00
|
|
|
assert schema.get("version") == version
|
|
|
|
|
assert TestInvocation(id="1").type == invocation_type # type: ignore (type is dynamically added)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_invocation_version_must_be_semver():
|
|
|
|
|
valid_version = "1.0.0"
|
|
|
|
|
invalid_version = "not_semver"
|
|
|
|
|
|
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
2023-09-24 08:11:07 +00:00
|
|
|
@invocation("test_invocation_version_valid", version=valid_version)
|
2023-09-04 09:16:44 +00:00
|
|
|
class ValidVersionInvocation(BaseInvocation):
|
|
|
|
|
def invoke(self):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
with pytest.raises(InvalidVersionError):
|
|
|
|
|
|
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
2023-09-24 08:11:07 +00:00
|
|
|
@invocation("test_invocation_version_invalid", version=invalid_version)
|
2023-09-04 09:16:44 +00:00
|
|
|
class InvalidVersionInvocation(BaseInvocation):
|
|
|
|
|
def invoke(self):
|
|
|
|
|
pass
|
2023-09-04 09:07:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_invocation_output_decorator():
|
|
|
|
|
output_type = "test_output"
|
|
|
|
|
|
|
|
|
|
@invocation_output(output_type)
|
|
|
|
|
class TestOutput(BaseInvocationOutput):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
assert TestOutput().type == output_type # type: ignore (type is dynamically added)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_floats_accept_ints():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = IntegerInvocation(id="1", value=1)
|
|
|
|
|
n2 = FloatInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "value", n2.id, "value")
|
|
|
|
|
|
|
|
|
|
# Not throwing on this line is sufficient
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_ints_do_not_accept_floats():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = FloatInvocation(id="1", value=1.0)
|
|
|
|
|
n2 = IntegerInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "value", n2.id, "value")
|
|
|
|
|
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
|
|
|
|
|
2023-10-17 06:23:10 +00:00
|
|
|
def test_polymorphic_accepts_single():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = StringInvocation(id="1", value="banana")
|
|
|
|
|
n2 = PolymorphicStringTestInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e1 = create_edge(n1.id, "value", n2.id, "value")
|
|
|
|
|
# Not throwing on this line is sufficient
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_polymorphic_accepts_collection_of_same_base_type():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = PromptCollectionTestInvocation(id="1", collection=["banana", "sundae"])
|
|
|
|
|
n2 = PolymorphicStringTestInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e1 = create_edge(n1.id, "collection", n2.id, "value")
|
|
|
|
|
# Not throwing on this line is sufficient
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_polymorphic_does_not_accept_collection_of_different_base_type():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = FloatCollectionInvocation(id="1", collection=[1.0, 2.0, 3.0])
|
|
|
|
|
n2 = PolymorphicStringTestInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e1 = create_edge(n1.id, "collection", n2.id, "value")
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_polymorphic_does_not_accept_generic_collection():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = IntegerInvocation(id="1", value=1)
|
|
|
|
|
n2 = IntegerInvocation(id="2", value=2)
|
|
|
|
|
n3 = CollectInvocation(id="3")
|
|
|
|
|
n4 = PolymorphicStringTestInvocation(id="4")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
g.add_node(n4)
|
|
|
|
|
e1 = create_edge(n1.id, "value", n3.id, "item")
|
|
|
|
|
e2 = create_edge(n2.id, "value", n3.id, "item")
|
|
|
|
|
e3 = create_edge(n3.id, "collection", n4.id, "value")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
with pytest.raises(InvalidEdgeError):
|
|
|
|
|
g.add_edge(e3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_any_accepts_integer():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = IntegerInvocation(id="1", value=1)
|
|
|
|
|
n2 = AnyTypeTestInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "value", n2.id, "value")
|
|
|
|
|
# Not throwing on this line is sufficient
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_any_accepts_string():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = StringInvocation(id="1", value="banana sundae")
|
|
|
|
|
n2 = AnyTypeTestInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "value", n2.id, "value")
|
|
|
|
|
# Not throwing on this line is sufficient
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_any_accepts_generic_collection():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = IntegerInvocation(id="1", value=1)
|
|
|
|
|
n2 = IntegerInvocation(id="2", value=2)
|
|
|
|
|
n3 = CollectInvocation(id="3")
|
|
|
|
|
n4 = AnyTypeTestInvocation(id="4")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
g.add_node(n4)
|
|
|
|
|
e1 = create_edge(n1.id, "value", n3.id, "item")
|
|
|
|
|
e2 = create_edge(n2.id, "value", n3.id, "item")
|
|
|
|
|
e3 = create_edge(n3.id, "collection", n4.id, "value")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
# Not throwing on this line is sufficient
|
|
|
|
|
g.add_edge(e3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_any_accepts_prompt_collection():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = PromptCollectionTestInvocation(id="1", collection=["banana", "sundae"])
|
|
|
|
|
n2 = AnyTypeTestInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "collection", n2.id, "value")
|
|
|
|
|
# Not throwing on this line is sufficient
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_any_accepts_any():
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = AnyTypeTestInvocation(id="1")
|
|
|
|
|
n2 = AnyTypeTestInvocation(id="2")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
e = create_edge(n1.id, "value", n2.id, "value")
|
|
|
|
|
# Not throwing on this line is sufficient
|
|
|
|
|
g.add_edge(e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def test_iterate_accepts_collection():
|
|
|
|
|
"""We need to update the validation for Collect -> Iterate to traverse to the Iterate
|
|
|
|
|
node's output and compare that against the item type of the Collect node's collection. Until
|
|
|
|
|
then, Collect nodes may not output into Iterate nodes."""
|
|
|
|
|
g = Graph()
|
|
|
|
|
n1 = IntegerInvocation(id="1", value=1)
|
|
|
|
|
n2 = IntegerInvocation(id="2", value=2)
|
|
|
|
|
n3 = CollectInvocation(id="3")
|
|
|
|
|
n4 = IterateInvocation(id="4")
|
|
|
|
|
g.add_node(n1)
|
|
|
|
|
g.add_node(n2)
|
|
|
|
|
g.add_node(n3)
|
|
|
|
|
g.add_node(n4)
|
|
|
|
|
e1 = create_edge(n1.id, "value", n3.id, "item")
|
|
|
|
|
e2 = create_edge(n2.id, "value", n3.id, "item")
|
|
|
|
|
e3 = create_edge(n3.id, "collection", n4.id, "collection")
|
|
|
|
|
g.add_edge(e1)
|
|
|
|
|
g.add_edge(e2)
|
|
|
|
|
# Once we fix the validation logic as described, this should should not raise an error
|
|
|
|
|
with pytest.raises(InvalidEdgeError, match="Cannot connect collector to iterator"):
|
|
|
|
|
g.add_edge(e3)
|
|
|
|
|
|
|
|
|
|
|
2022-12-01 05:33:20 +00:00
|
|
|
def test_graph_can_generate_schema():
|
|
|
|
|
# Not throwing on this line is sufficient
|
|
|
|
|
# NOTE: if this test fails, it's PROBABLY because a new invocation type is breaking schema generation
|
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
2023-09-24 08:11:07 +00:00
|
|
|
_ = Graph.model_json_schema()
|
