Usage of getters and setters for virtual and calculates attributes

[zirkelc]

Hi,

I'm trying to use getters, setters and watch to create a combination of calculated an virtual attributes. I have the three attributes contextId, contextType and contextUrl that I want to have as individual primitive attributes to be able to use them as secondary index.

However, when reading an entity I'd like to merge these three attributes into one object attribute context and hide the three individual attributes from the result. When setting the context, ideally, I'd like to set the context attribute and it distributes the values to the three attributes (or they react to the change of context via watch). The context attribute should only exist on the result, but not be persisted to the database.

Example:

await tasks
  .patch({ id: "1" })
  // this should set the values on contexId, contextType and contextUrl
  .set({ context: { id: "1", type: "product", url: "https://example.com" } })
  .go();

// result should contain context without contexId, contextType and contextUrl
const result = tasks.get({ id }).go();

Playground

Currently, context is persisted with the three attributes. I think to not persist context I would have to use set: () => undefined but then the other attributes would never receives an update. Maybe it's simply not possible to have this kind of dependency between attributes?

[tywalch]

Hi @zirkelc

Ultimately watch is more to help with some basic/common denormalization patterns, and less to perform object transformation. For those types of transformations, which I think this is one of those, it's ultimately left to the user to create the end-state objects they need. ElectroDB acts maybe less like an ORM and more like query builder in this regard.

[zirkelc]

Okay, that's what I thought. I just wanted to make sure I hadn't overlooked anything and that this is actually possible.

Thanks for the quick reply!

[tywalch]

One thing I'll add, to help you reason about why you did see what you had hoped in your case: Any attributes "watched" by another attribute will have their setters called prior to calling the setter of the "watcher". So in your case you'd lack a mechanism to prevent writing the context object