Small mismatch documentation & actual return type Uid

[unknown1337]

Dear,

When I create a new model entry using useRepo(someRepo).make() it returns {id: somenanoId, otherparms } while the documentation says it will return a uuid. This causes a problem due to a postgresDb existing table type mismatch.

Questions:

1. can I (without forking your project/ changing the npm_package and having to maintain updates myself) create a new @UidV4/ overwrite your @uid type?
2. I think either the documentation or the source code needs a small update.

thanks!

[CodeDredd]

True. Thanks for pointing it out. i switched to nanoid/unsecure. Thinking about a way so every User can define its One Attributes.
If i think it right its already possible and makes me think even more.

You could for example define a custom cast where you can have whatever uuid libary you want. I even think about removing Uid and starting some cast bundles with standalone casts for nanoid, uuid, whatever.

Let me know what you think about the last idea....but as more i think about it, its defently better to do it that way. So at the end i have

import UuidCast from './casts/UuidCast'
import { Model } from 'pinia-orm'
import { Str, Cast } from 'pinia-orm/decorators'

export class User extends Model {
    @Cast(() => UuidCast)
    @Str('') declare id: string
}

You can even define a own decorator where you make both together and then having something like @Uuidv4():

import type { CastAttribute, PropertyDecorator, TypeOptions } from 'pinia-orm'
import UuidCast from './casts/UuidCast'

/**
 * Create a cast & str for an custom Uuid
 */
export function Uuidv4( value: string | null, options: TypeOptions = {} ): PropertyDecorator {
  return (target, propertyKey) => {
    const self = target.$self()
    self.setCast(propertyKey, UuidCast)
    self.setRegistry(propertyKey, () => {
      const attr = self.string(value)

      if (options.nullable)
        attr.nullable()

      return attr
    })
  }
}

[unknown1337]

I even think about removing Uid and starting some cast bundles with standalone casts for nanoid, uuid, whatever.

Let me know what you think about the last idea....but as more i think about it, its defently better to do it that way. So at the end i have

-> cast bundles for pre defined items like nanoid, uuid seems great!
-> define decorator by user -> Tha seems relatively complex compared to a custom cast. I personally would go for the custom cast for that reason.

[unknown1337]

@CodeDredd , thanks. I am nearly there creating uuidV4 keys though I need a last tip:

import { Attr, BelongsTo, Cast, HasMany, Model, Str, Uid, CastAttribute } from "pinia-orm"
import { v4 as uuidv4 } from 'uuid'
class CustomCast extends CastAttribute {
  isUUIDd(s: string): boolean { // as set function gets called value = nanoid(); if so, replace it with uuidV4
    return s.match("^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$" || false);
  }
  get(value?: any): any {
    return value
  }
  set(value?: string): string {
    debugger
    return (value && this.isUUIDd(value)) ? value : uuidv4()
  }
}


export default class Group extends Model {
  static entity = 'groups'
  @Cast(() => CustomCast) @Uid() id: string
  @Str('') name!: string
  @Str(null, { nullable: true }) parentGroupId: string | undefined
  // @BelongsTo(() => Group, 'parentGroupId') parentGroup: Group | null
  @HasMany(() => Group, 'parentGroupId') childGroup: Group | null
  @Cast(() => CustomCast) @Attr('') testField: string

}
// recursion https://github.com/vuex-orm/vuex-orm/issues/436
// tree in SQL: https://www.codeproject.com/Articles/8355/Trees-in-SQL-databases

Scenario 1: @ repo.save({name:'hello', parentGroupId: null}) I get
Problem, the object key does not match the id field anymore. Does your code set the object key differently for @uid();?

Scenario 2: change @Cast(() => CustomCast) @Uid() id: string to @Cast(() => CustomCast) @Attr() id!: string results in an error:
runtime-core.esm-bundler.js:218 Uncaught Error: [Pinia ORM] The record is missing the primary key. If you want to persist record without the primary key, please define the primary key field with the `uid` attribute. at throwError (index.mjs:208:9) at assert (index.mjs:212:5) at Group.$getIndexId (index.mjs:1610:5) at EntitySchema2.<anonymous> (index.mjs:398:24) at EntitySchema2.getId (normalizr.es.js:137:17) at EntitySchema2.normalize5 [as normalize] (normalizr.es.js:151:19) at visit2 (normalizr.es.js:478:17) at normalize4 (normalizr.es.js:515:16) at Interpreter.normalize (index.mjs:436:12) at Interpreter.process (index.mjs:431:33)
Could it be that the id check is performed before the cast is executed?

Question: how could I fix my code s.t. I can create a new model 'object'/instance/row with repo.save({name:'hello', parentGroupId:null}) that has a uuidV4() id (object key and value)? thanks!

[CodeDredd]

@unknown1337 well it's out. Just released RC.6 🥳

[unknown1337]

Thanks for the release,some notes:

1. Are you sure that the new documentation is correct?

// import { Uid } from 'pinia-orm/uuid/v4'

Shouldnt this be
// import { Uid } from 'pinia-orm/***dist***/uuid/v4'

2. I think that in order to be able to provide an ID at insert (e.g. because the record came from a db),
   @Uid declare id: string
   should be
   @Uid('') declare id: string

3. a small note,although I like the changes in RC6! there are quite some breaking changes, especially for users that have a lot of models. Should I expect many more breaking changes towards the future as your package is already RC6? :)

Thanks!

[CodeDredd]

@unknown1337
to 1. Thanks for pointing out. I missed that part in the docs ^^....i wanted to make it that way like metioned but i released its more complicated with proper typings. Going to correct it in the docs.

To 2. I don't know what you mean here. It should be @Uid() declare id: string. There is no passing arguments since it doesnt make sence to provide a default because generating an id, is the default porpuse.

To 3. No i have no breaking changes more in mind. I think the next release will be 1.0.0. Right now i only work on features and bugfixes.

[unknown1337]

@CodeDredd , thanks for your quick reply!

1. great thanks!
2. agree, though then I think in the docs @Uid declare id: string should be @Uid***()*** declare id: string, do you agree?
3. wow, sounds great!

[CodeDredd]

Ok typos in docs fixed.
@unknown1337 Maybe you gonna like the new features 😉 #240