fix(firestore-bigquery-change-tracker): keep partition value on delete using old data

[CorieW]

Resolves #2303

• Tested

[Copilot]

Pull Request Overview

This PR updates the partitioning logic to retain the partition value on delete events by sourcing it from the old data rather than the new event data.

• Uses the new ChangeType import to differentiate between DELETE and non-DELETE events.
• Applies a conditional to select the appropriate field value for partitioning.

Comments suppressed due to low confidence (1)

firestore-bigquery-export/firestore-bigquery-change-tracker/src/bigquery/partitioning.ts:202

• [nitpick] Consider adding an inline comment explaining why event.oldData is used for DELETE events. This will improve clarity and maintainability for future developers.

event.operation === ChangeType.DELETE ? event.oldData[firestoreFieldName] : event.data[firestoreFieldName];

[cabljac]

lgtm as a fix, we will need to bump the change tracker package version?

[Copilot]

Pull Request Overview

This PR ensures that when a Firestore delete event occurs without new data, the BigQuery partition value is derived from the old data.

• Imports ChangeType and updates getPartitionValue to use oldData for delete operations.
• Adds a guard to early return when both data and oldData are null.
• Adjusts the fieldValue assignment based on the event’s operation.

Comments suppressed due to low confidence (2)

firestore-bigquery-export/firestore-bigquery-change-tracker/src/bigquery/partitioning.ts:209

• Using !fieldValue treats any falsy value (e.g., 0) as missing. If the partition field might legitimately be falsy, use a nullish check (fieldValue == null) instead.

if (!fieldName || !fieldValue) {

firestore-bigquery-export/firestore-bigquery-change-tracker/src/bigquery/partitioning.ts:196

• Add a unit test for the delete path to verify that the partition value is correctly pulled from oldData when event.data is null.

getPartitionValue(event: FirestoreDocumentChangeEvent) {

[cabljac]

lgtm!