[Bug] Inconsistent: newId() can't be assigned directly as id, but can be used directly in .byId()

newId() is returning an ID
image

but as part of the Document .create() function, ID is expected as Number or String

image

so the ID currently needs to be casted to a String if I want to assign it to an ID:

{
 id: newId().toString()
}

On the other hand .byId() accepts ID or Int
image

This is inconsistent, in my opinion. I suggest making it consistent by changing the Signature in both cases(create(), byId()) to ID and Int.

Hi @Mike This looks like a duplicate of this recent topic:

We have an internal ticket to extend the the create method to accept ID. Note my response in that topic, since there is rarely a reason (thank you for providing an example!) to perform MyColl.create({ id: newId(), ... }); the process that hands out keys for newId is the same one that auto-generates ids when you don’t provide an id field.

The byId method can already accept String | Int | ID. It does look like docs need updated, though, so I will pass that on.

Thanks, as always, for your feedback! Keep it coming :smiling_face:

Hi Paul, yes I’m aware of the other issue - I was already thinking if it would make sense to link it. I was creating a new issue, because my topic was mainly about the mentioned inconsistency between byId() & create() and because we have a real use case that is affected by this(Sorry for not mentioning the use case).

e.g. use case of adding a two-way reference between two new created documents (Discord Discussion):

let plan_id = newId()

Plan.create({
  id: plan_id.toString(),
  decision: Decision.create({
    plan: Plan.byId(plan_id)
  })
})

I’m glad to hear that you have an internal issue that this is tracking, so maybe this one can be the external issue, so I’m getting a notification when this is shipped :slight_smile:

Thanks for the clarification! I’ll add your use case to our internal ticket. It makes perfect sense to be able to use an ID directly for the id field.