ActiveObject-like object patch

[IlyaSemenov]

Relatively often I find myself using this (simplified) flow:

const order = await db.order.find(orderId).select("...", "paidTime")
if (!order.paidTime) {
  await db.order.find(orderId).update({ paidTime: new Date() })
  console.log(`Order was paid at: ${order.paidTime}`) // prints undefined
}

This is of course expected and I'm not complaining. However, this is still:

1. a gotcha, especially for newcomers
2. needs boilerplate for proper handling, such as:

await db.order
  .find(orderId)
  .update({ paidTime: new Date() })
  .afterUpdate(["paidTime"], ([data]) => {
    Object.assign(order, data satisfies Partial<typeof order>)
  })

My idea is, can we somehow simplify this on ORM level? Such as:

await db.order.find(orderId).update({ paidTime: new Date() }).patch(order)
// return all updated keys and set them in the provided DAO

Of course there are many questions, such as how to handle multiple objects, what to do if object has no respective keys (or what if they've been selected under aliases), etc. etc. — but I just wanted to start a discussion here.

Edit: see #410 as well.

[romeerez]

Your patch looks pretty neat. But, I'd like to avoid mutations, in the sake of smarter types.

I'd like to make it so that you can have a new variable updatedOrder with a proper type, so TS can see that this updatedOrder for sure has paidTime, while in the order it is optional.

I'm not sure yet how to design this better.

Thinking of:

// data has type { paidTime: Date }, and this should override { paidTime?: Date } of the order

const updatedOrder = await db.order.find(id).update(data).assign(order)

If you select some fields, it will populate selected fields + updated fields into the object:

// resulting type will have both foo and bar
const updatedOrder = await db.order.find(id).update({ foo: 1 }).select('bar').assign(order)

If it's findOptional, result can be undefined.

It's not patch because I'd like to avoid mutations. But assign is also a bad name, because Object.assign does mutate the object, and here I'd like to not touch the original order. merge? merge is already taken for merging queries. Need to research on naming.

Though, assign is a fine name. In a sense that it's assigning from order to updatedOrder, but not the other way around.

Seems to be fine so far. What do you think about my non-mutative idea over yours mutative one?

[IlyaSemenov]

Right, understood. Makes sense.

I see some rigidness now in the sense that paidTime could have been originally selected as aliasedPaidTime but there is no way to provide aliases for the updating fields in the proposed API. Not saying it's a big deal, just thoughts.

[IlyaSemenov]

Oh, I actually read your message above fully and discovered the "If some fields were selected, the data for update could be merged with selected data" proposal. That allows to account for aliased fields, but, how do we then prevent non-aliased updated paidTime being injected regardless what?

I think if there's at least one select, the fields in update should be disregarded. (Or even always disregard all fields in update and only assign those that are explicitly select'ed).

[romeerez]

how do we then prevent non-aliased updated paidTime being injected regardless what?

You're updating paidTime, and while such assign isn't super intuitive, still it's not a big surprise if you have paidTime in the output.

Maybe in your case it's not desired. In other cases it's in contrary expected. So it's clear by now that such assign (or patch) functionality is saving a bit of LOCs by taking from the code obviousness.

if there's at least one select

hidden rules

Or even always disregard all fields in update and only assign those that are explicitly select'ed).

then there is no point in assign, because the fields are selected anyway

[IlyaSemenov]

then there is no point in assign, because the fields are selected anyway

Not quite. Consider this:

const order = await db.order.find(id).select("id", "amount")
const updatedOrder = await db.order.find(id)
  .select("status", { time: "paidTime" })
  .update({ paidTime: new Date() })
  .assign(order)

I would expect updatedOrder to have id, amount, status and time (but not paidTime!)

[romeerez]

I agree by looking at your example that having both datas mixes is counter-intuitive.

In any case such assign addition won't be intuitive, and such JS destructuring is easier to follow:

const data = { paidTime: new Date() }

const updatedOrder = {
  ...order,
  ...data, // optionally include data if needed
  ...(
    await db.order.find(id)
      .select("status", { time: "paidTime" })
      .update(data)
  ),
}