Allow for [ObjectId] Modification

[andrewkimjoseph]

Algolia uses the Firestore document id as the object id. However, that can create limitations. Take this example:

• I have a collection called users
• have 3 users, say user1, user2, and user3.
• I have a concept called connections where users have relationships
• So, let's say user1 is connected to user3 and user2 is also connected to user3
• I will save the data in a subcollection like this:
  1. users/{user1}/connections/{user3}
  2. users/{user2}/connections/{user3}

In their specific contexts, they are different records, but when if I were to source my data from Firestore to Algolia using the phrase "users/{userId}/connections", the two records will be treated as the same (therefore duplicitous), meaning that one of them will be left out.

FIX During the Firebase extension configuration, we can enable objectId modification in such contexts. The question would be - "Collection path contains duplicate id? yes/ no"

Yes - the extension generates new objectId strings and save them to algolia No - current behavior continues

[razanor]

Another option to handle this would be to allow objectID modification inside a transform function. I actually assumed that it already works like that, but unfortunately it doesn't.

[smomin]

The Transform function gets the full payload for manipulation and enrichment, including the objectID. The Transform function can replace the object id what another id.

@andrewkimjoseph @razanor

[smomin]

Closing this since the object id can be modified in the transform function.

[ryankashi]

@smomin

Can you provide an example of what this transform function should look like? For some reason I am still not able to get this to work

[ryankashi]

****Hi @smomin this issue needs to be opened back up. Currently, ObjectID modification does not work as intended when deleting indexes from Algolia. Here is my following code for the Firebase transform function:

import { onCall } from 'firebase-functions/v2/https';

export const updateAlgoliaObjectID = onCall({region: 'us-west2'},({data}: any)=>{
    data.objectID = data.path;
    return data;
})

In this example, i set the objectID to a different key called path that is instead the full firestore path to that specific document, and we use this for the objectId instead. This works great, HOWEVER:

Algolia indexes are not properly deleted either through deleteDoc OR directly from deleting the document inside of the Firestore database. Modifying information in the document either via setDoc with {merge:true} or alternatively directly through the Firestore works fine.

This is due to the transform function not running when an index is deleted in Algolia. Can we please get a fix/status update regarding this issue?

[Luluno01]

@smomin How about just add a configuration option to use full document path as the object ID instead of document ID? It's simple and saves an extra unauthenticated endpoint.

[Kashi-Datum]

I agree. This is ubiquitous and allows for index-wide unique object IDs, while still allowing for documents across different subcollections to still share the same document name.

[smomin]

hey @Luluno01 @Kashi-Datum I have a branch on alt-objectId that I am working on that allows the use of any document property. I need to add the ability to use document path. I am hoping to get this done by this week.

[smomin]

hey @Luluno01 @Kashi-Datum try out the RC, https://console.firebase.google.com/project/_/extensions/install?ref=algolia/firestore-algolia-search@1.2.1-rc.0. This allows you to configure a different ObjectID.

[Luluno01]

hey @Luluno01 @Kashi-Datum try out the RC, https://console.firebase.google.com/project/_/extensions/install?ref=algolia/firestore-algolia-search@1.2.1-rc.0. This allows you to configure a different ObjectID.

Thanks for the update! Unfortunately, I found another issue that led to my own implementation of functionalities similar to what this extension does. More specifically, I want to index two collections with the same collection ID but slightly different fields, which are imported together by this extension into one index. This is, however, another issue that is unrelated to configuration ObjectID. Anyway, thanks for your help!

[smomin]

hey @Luluno01 any reason for not installing the extension twice so you are able to monitor the changes in two collections? You can install and configure the extension per collection and point it to the same Algolia index. I am just curious if I am missing something here.

[Luluno01]

hey @Luluno01 any reason for not installing the extension twice so you are able to monitor the changes in two collections? You can install and configure the extension per collection and point it to the same Algolia index. I am just curious if I am missing something here.

Thanks for asking. I tried installing the extension twice, but the issue is executeFullIndexOperation of both instances will import two different collections into the same index associated to them respectively -- because the collection ID is the same. Say I have a collection group /users/{uid}/teams and /teams which I want to index separately. In that case, executeFullIndexOperation will import both collection groups into the same index(es), which is undesirable. I know I can use the transform function to add marks to the objects and then filter them by that mark, but it takes an unauthenticated transform function which I really want to save. And yes, I should have made these two semantically (slightly) different collection groups in different IDs, but that cannot be changed since the migration seems like a bigger hassle.

[smomin]

Any feedback on the RC release to configre another ObjectID