Issue with Entity Modification and Query Results

[daniel7byte]

I have encountered an issue with my current setup involving the entities Users and Pets (code attached). Initially, when I create a Pet for a User, everything works as expected. Queries to retrieve all Pets or to filter by Users return the correct results.

However, the problem arises when I edit a Pet. Although the edit is successful, the Pet no longer appears in the query results of the ByUserIdCollection. This discrepancy occurs because the "gsic5sk" value changes upon editing.

During creation, the gsic5sk is set to $users#pet_1. Subsequently, in the ByUserIdCollection query, it matches $users#pet_1 and retrieves the record successfully. However, after an UPDATE/PATCH operation, the gsic5sk changes to $users, which disrupts the ByUserIdCollection query as it fails to find the record.

Playground Link

import { Entity, Service } from "electrodb";

const table = "doru";

/* Tasks Entity */
const PetEntity = new Entity({
    model: {
      entity: "pet",
      version: "1",
      service: "doru"
    },
  attributes: {
    version: { type: 'number', required: true, default: 1 },
    createdBy: { type: 'string', readOnly: true },
    updatedBy: { type: 'string' },
    createdAt: { type: 'number', readOnly: true },
    updatedAt: { type: 'number', readOnly: true, watch: '*' },
    // Pet attributes
    petId: {
      type: 'string',
      required: true,
    },
    userId: {
      type: 'string',
      required: true,
    },
    name: {
      type: 'string',
    },
    breed: {
      type: 'string',
    },
    kg: {
      type: 'string',
    },
    specie: {
      type: 'string',
    },
  },
  indexes: {
    // Access patterns
    primary: {
      pk: { field: 'pk', composite: ['petId'] },
      sk: { field: 'sk', composite: [] }
    },
    list: {
      index: 'gsi1',
      pk: { field: 'gsi1pk', composite: [] },
      sk: { field: 'gsi1sk', composite: ['petId'] }
    },
    // Collection indexes
      byPetIdCollection: {
        collection: "pets",
        type: 'clustered',
        index: 'gsic6',
        pk: { field: 'gsic6pk', composite: ['petId'] },
        sk: { field: 'gsic6sk', composite: [] }
      },
       byUserId: { // FIX
        index: 'gsi5',
        pk: { field: 'gsi5pk', composite: ['userId'] },
        sk: { field: 'gsi5sk', composite: [] }
      },
      byUserIdCollection: { // ERROR BEFORE UPDATE/PATCH
        collection: "users",
        type: 'clustered',
        index: 'gsic5',
        pk: { field: 'gsic5pk', composite: ['userId'] },
        sk: { field: 'gsic5sk', composite: [] }
      }
  }
  },
  { table }
);

PetEntity.create({
petId: '1',
userId: "abc1123"
}).go()

PetEntity.patch({ petId: "1" })
    .set({})
    .add({ version: 1 })
    .where((attr, op) => op.eq(attr.version, 1))
    .go({ response: 'all_new' });

PetEntity.query.byUserId({userId: "1"}).go({})

PetEntity.query.byUserIdCollection({userId: "1"}).go({})

To address this issue, I have implemented Access Patterns without the following attributes:

collection: "users",
type: 'clustered',

Is this approach correct? Is it a bug in the system, or is there a preferred method for handling this situation?

Thank you for your assistance and insights.

[daniel7byte]

Update: I had been thinking that #pet_1 was the sk, but no, I found that it's the $entity_version. And then, that's even stranger to me.

[daniel7byte]

Issue solved in: #413