@joshhytr

Hi, I rerolled Andy's patch for version 2.0.3 and opened an MR.

Thanks

joshhytr → made their first commit to this issue’s fork.

I've just realised because I have access to the index in the prepareFilters() function I can get the server instance and its BE config.

This is not required. Cheers

Thanks Scott!

I've updated the MR with the suggested change and fixed the phpcs issue.

And yes, re the coordinated release.

joshhytr → created an issue.

joshhytr → created an issue.

joshhytr → created an issue.

Thanks for the talk! Really interesting discussion and great to see the walkthrough of ai_search.

Brilliant, thanks for your help!

I'll go for postgres.

vdb_provider_postgres in the short term and for this fork.

I'll create a stub ai_vdb_provider_postgres module page for the beta and port there once this issue has been merged.

The version I have at the moment does handle the 'filters' string passed to querySearch or vectorSearch.

I've yet to implement the prepareFilters and prepareConditionGroup functions, that's my next task, but I do intend for it to be able to run a vector similarity search on a filtered subset of results.

This module/plugin will only be used when working with vectors and maybe the specificity of 'pgvector' implies that use case and the extension requirement. As you say, core and search_api_db cover the native postgres use cases.

But I'm still unsure given pgvector is not actually the engine and ai_vdb_provider_postgres somewhat namespaces itself within the vector space. Maybe postgres is the more proper name.

Hey Scott,

Sounds great. I'll definitely come along to the meetup.

With regard to the module naming, I am of two minds. I've seen postgres with pgvector simply referred to as pgvector in a few spaces online, but given postgres is the actual engine that's powering it, maybe that is the better name. Do you think so?

joshhytr → created an issue.

JoshHytr → created an issue.

JoshHytr → created an issue.

Hi @scott_euser,

I found the old/empty config values were being used by the client during the validation.

I've opened an MR (80) to set the new values on the instance before attempting to validate.
This resolves the issue for me.

This is already implemented for the Milvus plugin.

Thanks

JoshHytr → made their first commit to this issue’s fork.

Hi both, I've resolved the merge conflicts on the issue fork.

I've prioritised changes from 1.0.x unless change is specific to this issue.

Would you be able to confirm the MR still has all relevant changes, please scott_euser?

Thanks

JoshHytr → made their first commit to this issue’s fork.

JoshHytr → created an issue.

JoshHytr → created an issue.

JoshHytr → created an issue.

JoshHytr → made their first commit to this issue’s fork.

A cryptography library of choice can be used to generate an RSA private key and, using that key, a x509 certificate key pair can be generated.

Whilst generating the certificate, the email address relevant to the OAuth should be included somewhere in the identity/subject certificate. When using openssl, I entered the OAuth email in the email address prompt.

Using openssl:

openssl genrsa -out private.key 2048
openssl req -new -x509 -key private.key -out publickey.cer -days 365

The public key should be uploaded to Azure, to the SMTP OAuth app, in place of using the client secret. Azure should then provide a thumbprint of said certificate which should be made note of and added to this module's settings form as the ms_public_key_thumbprint.

The private key should be stored somewhere secure on the Drupal web server. This should not be accessible from the web and is a secret. The key and certififcate should not be committed to source control. The absolute path to this key should be added to this module's settings form as the ms_private_key_path.

I stored my private key in a dedicated OAuth directory outside of the docroot:
/app/oauth/cert/private.key
where
/app/docroot
is my Drupal docroot.

Note: I do not have access to Azure so I cannot give more detailed descriptions/terminology relevant to the that part of the setup. Apologies for this.

Thanks imclean, agreed there's some tidying that could be done. I shall take a look at the suggestions and implement if I get some time.

I've pushed initial work to the fork's issue branch.

Still needs thinking and further work to ensure a refresh token can be used to generate a new access token whilst using this authorization flow.

JoshHytr → created an issue.

Hi spalmstrom,

I was seeing similar issues to you and switching the order in which the module was requesting application scopes got it working for me.
This is due to some MS API changes and deprecations.

Please see my separate issue with solution, hopeful that it helps you too:
https://www.drupal.org/project/phpmailer_oauth2/issues/3335826 🐛 Re-order requested scopes Fixed

Thanks

I've pushed the small change to the issue fork.

Apologies for the duplicate branches - I hadn't realised drupal.org auto-generated one. I've added the work to both for consistency.

I'll open an MR from the drupal.org generated branch.

JoshHytr → created an issue.