[Python API feedback] Additional properties

General
1

Hi Weaviate community - we are looking for your feedback on some experimental changes to the Python API.

One area is how we specify additional properties. What do you think about this proposal?

from weaviate import AdditionalProperties

results = (
    client.query.get("Article", ['title'])
    .with_additional(
        AdditionalProperties(
            vector=True,
            uuid=True,
            creationTimeUnix=True,
            lastUpdateTimeUnix=True,
            distance=True,
        )
    )
    .with_limit(2)
    .do()
)

This would replace:

results = (
    client.query.get("Article", ['title'])
    .with_additional(
        ["vector", "id", "creationTimeUnix", "lastUpdateTimeUnix", "distance"]
    )
    .with_limit(2)
    .do()
)

We would love to get your thoughts on the idea, and the specific syntax. Let us know in the thread!

To test this out - I believe you’ll need to pull the latest version of the Python client from the repo, and on this server:

client = weaviate.Client(
    url="https://edu-demo.weaviate.network",
    auth_client_secret=weaviate.AuthApiKey(api_key="learn-weaviate"),
)
3 Likes
2

Looks like a great progression towards abstracting away the underlying GraphQL protocol from the user, well done team! I like this syntax as it achieves a similar feel to the implementation that can be achieved within TypeScript like .withAdditional({ vector: true }).

Can it also be safely assumed that not all the kwargs need be specified? I.e., AdditionalProperties(vector=True) is valid returning only the vector field since the other kwargs default to None and are interpreted as False?

Finally, will this syntax be developed further to account for nested Additional Properties, like classification and group as documented here?

1 Like
3

I like the change – however, is the AdditionalProperties wrapper necessary?

1 Like
4

Now you’re saying it, no, not really :sweat_smile: . I’ll make a PR without it and see how it feels

1 Like
5

yes, that is the goal. But we wanted to get some feedback for the general mechanism before implementing more

1 Like
6

Add with_metadata by dirkkul · Pull Request #381 · weaviate/weaviate-python-client · GitHub - please have a look here :slight_smile:

I’m taking proposals for better names. In general we want to try to hide the inner workings of GQL in the basic commands