Type of timestamp value is better dictionary type than number

[mtfum]

Hi, Thank you for all your help!

I started to use this extension lately and realized the value of the timestamp will be changed to a number of milliseconds. ref: https://github.com/algolia/firestore-algolia-search/blob/main/functions/src/processors.ts#L62

I need to do anything another when decoding the struct which includes another type like this. Are there some reasons to have it as a number type? Moreover, my suggestion is to use a dictionary type like GeoPoint

What do you think? Sorry if it's my misunderstanding, thank you!

[Haroenv]

I'm not sure if I understand your question correctly, but we have a config.transformFunction which can be a cloud function to transform the record before indexing.

[mtfum]

I see I can transform the record as I want.

A type of timestamp in Firestore is saved as a type of number only the number of milliseconds in Alolia so far. As default, why don't we save a type of timestamp like the below code?

const processTimestamp = (timestampVal: Timestamp) => {
  return {
    seconds: timestampVal.seconds,
    nanoseconds: timestampVal.nanoseconds
  }
}

[smomin]

Hey mtfum, representing timestamp in milliseconds is a known and universal standard for representing time. We are coding against best practices and standards. If you want to make any customization, you can definitely fork this repo and make you change and deploy your version to your firestore instance.

[mtfum]

Ok, it makes sense to me. Thank you for your advice.

[davidoort]

Hey @smomin , I have a similar question to @mtfum around timestamps. We're syncing to Algolia so that we can do easy search over firebase documents. However, when we inspect the synced documents in Algolia, the timestamps are not in a readable format (see screenshot).

Whereas in Firebase they are, as seen in the second screenshot:

Also Algolia doesn't allow doing facet filtering based on a timestamp field as far as I'm aware, which would be super useful.

How can we get timestamps into a timestamp format in Algolia (if there is one) instead of an int format?

[davidoort]

Hey @smomin any updates on this?

[smomin]

Hey @davidoort I have not had a chance to review your use case. Please look into using the transform function if you need something immediately.

[go-sean-go]

Just to add, as @smomin mentioned, Algolia stores dates via Unix typestamp per: https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/in-depth/what-is-in-a-record/#dates

As a consumer of this extension, I would NOT want that to change, because I need my data to be searched and sorted by Algolia - limitations and all - and Algolia expects dates to be in this Unix timestamp format.

On the return value (client) side, if clients are searching an Algolia index, they are consuming Algolia data (not Firestore data). The core of the data is sync'd to Firestore, but several field types are not: timestamps are one, location is another that is transformed to something else. Still, the return value should be in Algolia's format.

If it's useful, here is what we use to convert an Algolia response to something that matches our TypeScript types in our React Native app:

import firestore from '@react-native-firebase/firestore';

...

const index = algoliaClient.initIndex('index_name');
const response = await index.search(
  query,
  options,
);
const hit = response.hits[0];

const {lat, lng} = hit._geoloc;
const firestoreGeopoint = new firestore.GeoPoint(lat, lng);

const firestoreUpdatedAt = new firestore.Timestamp(hit.updatedAt / 1000, 0);

While this loses nanosecond precision, I don't think there is a way around that (though you could look-up your Firestore document in parallel and use that value if you need it), but note that the same loss of precision occurs when you use Firestore's built-in toDate() function.

Basically: nanoseconds are a Firestore thing, and it's highly unusual in my experience (though that's debatable).

Hopefully the transform code above is helpful - but mostly I just wanted to vote for making sure our data stays aligned to Algolia standards and not something bespoke in this case.