Just realeased for you the fix https://github.com/CodeDredd/pinia-orm/releases/tag/pinia-orm%401.6.1 . It's fine. Maybe somehow you get it to work with sending me a coffee 😄

Thank you very much, I will test it as soon as possible. Unfortunately, GitHub has banned me from buying a coffee for you due to economic restrictions. Therefore, my payment failed.😪

But in any case, I would still like to help and address the issue. I have created a ticket to the GitHub support team. Once it is resolved, if possible, I will be more than happy to buy you a coffee.

I have tested it and it works perfectly. However, I have a question. If I create an object with const user = useRepo(User).new(false), the object is returned with an id value. So, how can I tell if the object has been saved or just created for future reference?

Maybe we should not generate an id if the object has just been created and not yet saved?

I asked because someone has a fairly extensive application, and in certain instances, they would like to determine if an object has been saved or simply created in an easy way.

What do you think?

Hmmm....i get your point. But then you need to use just @Attr for id. Then you will have the outcome you want. @UId will always create an id because maybe you use it for an not id field.

I am still thinking if this easy solveable or needed at all since you can define ids as not uid. But it kind of feels right to make it that way you say it.

I believe that using @Attr for the primary key is not a problem in most cases. I have only used @UId in testing scenarios, and I will change it to @Attr because it will help me with relations. Currently, the relations are not working as expected and documented with @UId, but that is another story.

saving is just a shortcut if need the same logic for updating or creating.
I think the wording is just cofusing you. saving is more the synonym for creatingOrUpdating

Okay, but we have a problem here. Where is the hook named hookBeforeSavingData that specifically fires before the model is saved? I really need such a hook for my app because I need to do some things before the models are saved to the Pinia storage.

Take a look:
#1106 (reply in thread)

Maybe the hook named saved will be useful for me, but I'm not sure at the moment.

I believe I have a way to hook Pinia's storage before using the ORM to write data, although I'm not yet sure how to execute it. Still, I'm optimistic that it can be done.

I will think about it and write a proposal for you outlining the name and method for implementing the hook. In any case, I will do my best to ensure its success.

I will need some time to read through the documentation on how the other library was created and how they named their hooks.

Okay, but we have a problem here. Where is the hook named hookBeforeSavingData that specifically fires before the model is saved? I really need such a hook for my app because I need to do some things before the models are saved to the Pinia storage.

This hook is creating where you also return false to prevent saving to the store. All hooks creating, updating, saving & deleting are called before the store is updated.

This hook is creating where you also return false to prevent saving to the store. All hooks creating, updating, saving & deleting are called before the store is updated.

I also do not understand how returning false works in creation hooks. It seems like it discards the instance creation.

User.ts

import { Model } from "pinia-orm"
import { Attr, Str, Uid } from "pinia-orm/dist/decorators"

class User extends Model {
    static entity = "user_profiles"

    @Uid() declare id: string
    @Str("") declare name: string

    @Attr(null) declare createdAt: number
    @Attr(null) declare updatedAt: number

    static creating(model: Model) {
        console.log("creating")
        if (model.createdAt == null) {
            model.createdAt = new Date().getTime()
        }

        if (!model.name) {
            model.name = "set some name"
        }

        return false
    }

    static updating(model: Model) {
        console.log("updating")
        model.updatedAt = new Date().getTime()
    }

    static saving(model: Model) {
        console.log("saving")
        model.updatedAt = new Date().getTime()
    }
}

export { User }

I returned false in the creating hook, and I did not expect to see the message saving. Also, userProfileRepo.new(false) does not return an instance of the model for me.

creating
saving

AssertionError: expected null to be truthy

import { afterEach, beforeEach, describe, expect, it } from "vitest"
import { createPinia, type Pinia } from "pinia"
import { createORM, Model, Repository, useRepo } from "pinia-orm"

import { User } from "./User"

describe("User", () => {
    // Define some variables that will be used in the tests
    let pinia: Pinia
    let userProfileRepo: Repository<User>
    beforeEach(() => {
        pinia = createPinia().use(createORM())
        userProfileRepo = useRepo(User, pinia)
    })

    afterEach(async () => {
        Model.clearRegistries()
    })

    it("userProfileRepo.new(false)", () => {
        expect(userProfileRepo.all().length).toBe(0) // double check
        // hook creating fired because new instance
        const user = userProfileRepo.new(false)!
        expect(user).toBeTruthy() // ERROR IS HEREEE

        expect(userProfileRepo.all().length).toBe(0)

        // hook creating MUST NOT fire because NOT new instance
        userProfileRepo.save(user)
        expect(userProfileRepo.all().length).toBe(1)

        // Assert that the createdAt and updatedAt fields are set correctly.
        expect(new Date(user?.createdAt!)).toBeInstanceOf(Date)
        expect(new Date(user?.updatedAt!)).toBeInstanceOf(Date)
        expect(user.name).toBe("set some name")
    })
})

I believe that naming and implementing the hooks's logic in a different way might be better.
Here's a proposal:

We have hooks named before:

• beforeCreated, called before instance is created
• beforeSaved, called before instance is saved
• beforeUpdated, called before instance is updated

We also have hooks named after:

• afterCreated, called after instance is created
• afterSaved, called after instance is saved
• afterUpdated, called after instance is updated

Additionally, we could have optional hooks named do to replace the current logic:

• doCreated, to replace created logic
• doSaved, to replace saved logic
• doUpdated, to replace updated logic

Some use cases:

1. If I create a new instance with const user = useRepo(User).new(false), the beforeCreated hook should be fired because it is a new model instance. The beforeSaved hook should not be fired because the model has not been saved yet. Additionally, the beforeUpdated hook should not be fired because it is a completely new model.

2. If I create a new instance with const user = useRepo(User).new(true), hooks should be fired: beforeCreated, beforeSaved, because the model is being saved and created. The beforeUpdated hook should not be fired because it is a completely new model.

3. If I update my instance, the beforeUpdated hook should fire because I am updating the model. It does not matter how the instance was created because the update operation implies that the instance already exists. The beforeSaved hook should not fire because updating the model does not necessarily mean it will be saved.

P.S.
Having optional hooks named do to replace the current logic could be interesting, but it is important to note that it may introduce confusion. For example, if we replace the doSaved hook with "nothing", the model will never be saved, which could be very funny 😀.

FOUND it 🎉 ....released again and fix. Now everything is correct. Try v1.6.4

Btw... I don't know if you know it and if it is waht you need. But there is meta field if you need updatedAt and createdAt. https://pinia-orm.codedredd.de/guide/model/getting-started#meta-info

FOUND it 🎉 ....released again and fix. Now everything is correct. Try v1.6.4

Yeah, I took a look at 519681c. I'm sorry, I should have been more clear in my previous messages.

However, I have a problem. I'm not very experienced with JavaScript, which can sometimes make it difficult for other people to understand how I describe certain things.

It's all ok 😉 .... sometimes i get self confused by my own words 😆

Btw... I don't know if you know it and if it is waht you need. But there is meta field if you need updatedAt and createdAt. https://pinia-orm.codedredd.de/guide/model/getting-started#meta-info

Yes, I have seen it. However, there are certain situations where I prefer to rely on my own logic so that I can better understand and meet my needs. This is especially true for my app, which will both receive and send data to an Electron app.

         Vue.js App                      DataProfileModel (read storage) 
             │                                   │
             │   Write data to                   │
             ▼   Electron API                    ▼
     dataProfileModelPlugin.ts <───IPC───>      Electron
             │                                   │
             │    Read and write data to         │
             ▼    Electron State                 ▼
        Pinia ORM State                     Electron State
             │                                   │
             │    Read data from                 │
             ▼    DataProfileModel               ▼
      DataProfileModel                      DataProfileModel (write to storage)

Vue.js app communicates with Pinia ORM to manage data. Pinia ORM communicates with DataProfileModel to read/write data. dataProfilePlugin.ts bridges Vue.js app and Electron using IPC for CRUD operations on DataProfileModel. Electron updates Electron state, which syncs with Pinia ORM state. Updates to Pinia ORM state are reflected in Vue.js app's UI.