to share some first impression. The API is indeed smoother. However, for schema I prefer the json way, as it let us store the schema elsewhere. We have an internal toolkit used for several project, and having everything in code is not possible. Right now we create with legacy API the schema and import with the new one.
Oh that’s an interesting data point. Would it work for your use case if we added a method to fetch the full, JSON definition for the collection? (Like a articles.config.get() or articles.config.raw() method, where articles is the collection).
Or would you also want the collection creation to take JSON inputs?
Hi, I’m looking at the python v4 client again now that it works with wcs and the query fetch_objects function returns a _QueryReturn containing _Object objects.
Is there any particular reason these return internal classes? I’m writing a function to map the response objects but can’t have proper typing unless I imported _Object from the internal package which I guess isn’t an intended workflow.
It can be done without typing but that seems a waste when the classes are already there.
Thanks, that’s true but only if you’re using the response object in the same function that ran the query because it knows the return type. That’s not the case in other functions.
As an example, I have multiple functions that run different weaviate queries. I need to map the list of returned weaviate objects to domain objects and I don’t want to do this in every method that runs a query so I use mapping functions. With the way it is currently, any functions like this cannot have typing.
Overall though the new client is nice. Definitely a cleaner dev experience.
I brought this up with the devs, and looks like they generally agree with you. I can’t make any promises, but at this point we’re looking at exposing those classes through a separate submodule (so as to not clutter weaviate.classes).