Pinecone embedding store

[jmartisk]

No description provided.

[geoand]

CI seems to complain :)

[jmartisk]

It's now failing because of an ambiguous dependency in the examples code.
An EmbeddingStore injection point can now have a Redis or Pinecone store. Do we really need to treat the examples as a valid Quarkus application a build it (

quarkus-langchain4j/docs/pom.xml

Line 74 in 6f40a9d

<goal>build</goal>

)? I fail to see what purpose this has

[geoand]

Yeah, we want to sample applications to build as we point users to them all the time.

For the docs, you can just comment out the extension

[cescoffier]

It should be possible to inject the dedicated type (PineconeStore or whatever the name is) and avoid ambiguous dependency. In other parts of the doc, I mentioned that if there is only one bean of the given type in the application, you can inject it using DocumentStore.

[jmartisk]

I've updated the docs to add Pinecone docs and resolve the ambiguities..
For the CI, the problem is that we only have one Pinecone index that is shared, so this is how I'm proposing it to work:

• If we detect that secrets are enabled (it needs the PINECONE_API_KEY variable) then we set max-parallel to 1 to avoid running the test twice in parallel
• If secrets are disabled (the workflow was triggered by a PR from a fork....) then the PINECONE_API_KEY variable doesn't exist and the test is skipped, but we keep max-parallel at a bigger number, because it's not necessary to limit the concurrency in this case
• In the nightly build (build-against-langchain4j.yml) the test will run.. with a max-parallel of 1

[geoand]

Does @Inject EmbeddingStore work too?

[jmartisk]

Right now, @Inject EmbeddingStore works, but if #73 is OK I will update also it here to accept @Inject EmbeddingStore<TextSegment>, it's better than using the raw type

[geoand]

Right, let's rebase this after that one is in