Repository piniaStore() returns different piniaStoreInstance, when using a derivedModel

[adm-bome]

Why does the Repository uses the $entity() as a name for the Pinia Store, while the Query uses the $baseEntity(). Is this by design or by mistake?

pinia-orm/packages/pinia-orm/src/repository/Repository.ts

Lines 117 to 119 in 43126f6

	piniaStore<S extends DataStoreState = DataStoreState>() {
	return useDataStore<S>(this.model.$entity(), this.model.$piniaOptions(), this.query())(this.pinia)
	}

pinia-orm/packages/pinia-orm/src/query/Query.ts

Lines 163 to 172 in 43126f6

	protected commit(name: string, payload?: any) {
	const store = useDataStore(this.model.$baseEntity(), this.model.$piniaOptions(), this)(this.pinia)
	if (name && typeof store[name] === 'function')
	store[name](payload, false)
	if (this.cache && ['get', 'all', 'insert', 'flush', 'delete', 'update', 'destroy'].includes(name))
	this.cache.clear()
	return store.$state.data
	}

When creating a Model extended from an other Model we use baseEntity in the exteded Model.

// Base entity.
class Person extends Model {
  static entity = 'person'
  static types () {
    return {
      PERSON: Person,
      ADULT: Adult
    }
  }
  static fields () {
    return {
      id: this.attr(null),
      name: this.attr('')
    }
  }
}

// Derived entity.
class Adult extends Person { 
  static entity = 'adult'
  static baseEntity = 'person'
  static fields () {
    return {
      ...super.fields(),
      job: this.attr('')
    }
  } 

When we use the following code, a store is created with the name adult

const repo = useRepo(Adult)
const store = repo.piniaStore() // Wrong StoreInstance

But when we use the following code a store is created and data is saved into the piniaStoreInstance with the name person

const repo = useRepo(Adult)
repo.save([{ id: 1 }])

[adm-bome]

As a suggestion i would implement something like an method piniaStoreName into the model class.
The naming within the Piniastore is more flexible.

class Model {
  ...

  static piniaStoreName
  static piniaStoreNamePrefix

  $piniaStoreName() {
    return [this.$self().piniaStoreNamePrefix, this.$self().piniaStoreName || this.$baseEntity()].filter(v => v).join('/')
  }

  ...
}

class Query {
  ...

  commit(name, payload) {
    const store = useDataStore(this.model.$piniaStoreName(), this.model.$piniaOptions(), this)(this.pinia);

    ...
  }
  
  ...
}

class Repository {
  ...

  piniaStore() {
    return useDataStore(this.model.$piniaStoreName(), this.model.$piniaOptions(), this.query())(this.pinia);
  }

  ...
}

[CodeDredd]

I dont know which benefit i get because the static entity prop already reflects the name of the pinia store.
Isn't it confusing if a model can open a different pinia store which doesn't refelct the model ?

[adm-bome]

When a developer only uses PiniaORM, you're right it is confusing. The developer is most likely not using this functionality.

But when a developer or project uses mixed Pinia Stores and PiniaOrm Model Stores, the possibility of stores conflicting with the storename becomes highly possible.

Wouldn't it be nice to give an escape out of the box. like piniaOptions are passed to the store when created, but there is no way of altering your storename from within the ORM codebase.

It solves:

• The $entity() / $baseEntity() calls by always using $baseEntity(). $baseEntity() calls $entity() when no baseEntity prop is set on the model.

By calling a method $piniaStoreName(), It adds the ability:

• to use/rename the storeName differently than the actual model name. (only if needed.)
• to use a prefix to prevent duplicate stores. (like vuex did, by module namespacing)
• to override the method piniaStoreName(), when a developer needs a different outcome, without interfering with the outcome of $entity() and $baseEntity() methods.

These $entity() and $baseEntity() methods are used in several places in the code base and so are "reserved" and you don't want to mess with these methods. So by using a separate method like $piniaStoreName() the storename is isolated and can be altered without interfering with the outcome of $entity() and $baseEntity() methods.

As an example prefixed stores for the orm. (which i find better readable, and not confusing)