pocketbase icon indicating copy to clipboard operation
pocketbase copied to clipboard

Feature Request: Special Increment field value

Open kidus-tiliksew opened this issue 3 years ago • 4 comments

It would be extremely useful to have an increment field value similar to what we have with firestore. It should be able to automatically update the counter based on user input. The calculation happens on the server side.

kidus-tiliksew avatar Oct 16 '22 18:10 kidus-tiliksew

It could be added but I'm not sure what is the real use case for this. The illustrated example has very limited usage and the only benefit I see is the "safe" concurrent writes (still one of the writers could submit -99999 to reset the counter and override it).

@kidus-tiliksew Could you elaborate on your use case and why do you think it would be useful?

ganigeorgiev avatar Oct 16 '22 18:10 ganigeorgiev

A FieldValue.increment(-99999) field value would not override the existing value but rather subtract from it in a safe transactional way.

I don't remember all the use cases but I have used the increment value on Firestore many times before, one I remember is incrementing the number of likes a blog post gets. I imagine it's useful to a lot of people

kidus-tiliksew avatar Oct 16 '22 18:10 kidus-tiliksew

@kidus-tiliksew I'm not sure that I understand what do you mean by "safe transactional way". There are no transactions here. Every writer will just operate (substract or add) based the last stored value. The concurrent "safety" in Firestore to some extend comes also from the fact that they restrict the updates to the same document to only 1 write per second (or at least that was the case a year ago).

I could understand the example with the likes counter. I'll have to think a little more on this before adding it to the roadmap, because I want to avoid bloating the field dropdown with unnecessary types. Eventually this could be integrated as an option to the existing number field type.

ganigeorgiev avatar Oct 16 '22 18:10 ganigeorgiev

When I said "transactional", I wasn't necessarily talking about implementation, I just meant to say it should be accurate. If multiple users are operating on the same counter field, the last stored value might not be the same for all, and so definitely won't be accurate unless there is special implementation for it.

Thanks for the responses ✌️

kidus-tiliksew avatar Oct 16 '22 19:10 kidus-tiliksew

This is implemented in the latest v0.11.0 release via the + or - field modifiers - https://github.com/pocketbase/pocketbase/releases/tag/v0.11.0:

{
    // oldValue + 2
    "someNumberField+": 2
}

ganigeorgiev avatar Jan 08 '23 10:01 ganigeorgiev

Is it possible to add rules on the field only to update +1 per request, not -99999? Maybe something like @request.data.field+ = 1 or (field + @request.data.field) = (field + 1)(?)

terdampar avatar Feb 25 '23 15:02 terdampar

@terdampar No, sorry this is not planned at the moment since it will complicate too much the filter syntax and internals.

For more advanced server-side validations you can register a OnModelBefore* or OnRecordBefore*Request hook

ganigeorgiev avatar Feb 25 '23 15:02 ganigeorgiev

@ganigeorgiev Could you please provide a short example on how to use field modifiers? I couldn't find anything in the docs except that supported modifiers column under "Collections" Would highly appreciate it, thanks!

bart avatar Feb 28 '23 08:02 bart

@bart I'll consider documenting it better, but in general field modifiers are just an extra suffix to the field name:

await pb.collection("example").update("RECORD_ID", {
    "totalA+": 10, // old totalA + 10
    "totalB-": 20, // old totalB - 20
})

ganigeorgiev avatar Feb 28 '23 08:02 ganigeorgiev

Ah okay, got it. Thanks @ganigeorgiev So it's just an increment of the current field value on update and not an auto increment over all fields in that collection on creation, correct?

bart avatar Feb 28 '23 11:02 bart

@bart Yes, that's correct. The field modifiers operate only on their related record field value.

ganigeorgiev avatar Feb 28 '23 11:02 ganigeorgiev