Custom primary keys, upsert, transactions, etc #545
Unanswered
benallfree
asked this question in
Q&A
Replies: 1 comment
-
I'm not planning adding support for custom primary keys. It'll add too much complexity to the internals. About the upsert+query and transactions: Similar requests were filed in the past (ex. #455), but for now I'm not planning supporting single create/update+query type operations, because the query could return more than 1 record and its not clear which one will be updated. Bulk transactational create/update/delete from the same collection (where you'll able to specify a query filter) would be handled in #48 after the ongoing refactoring. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Ok this is a mashup of topics, hopefully not too convoluted.
Custom Primary Keys
I'm finding some friction where all the API calls require a reference to the
id
column, which is sometimes not known. What I may know, for example, is the user ID.It would be nice to perform an operation like that. Right now, I believe I have to query for the preference record, get the ID, then issue the update. But if I could just say that UID is the primary key, everything would be much easier.
Upsert
Currently, a query+(insert|update) introduces a race condition. Instead of:
It would be great to just do this and have it work inside a transaction:
Transactions
It would be awesome to issue several collection updates inside a transaction:
The above would be translated into some serializable object structure that PocketBase would know how to run inside a transaction.
I'm eager to contribute in the most helpful way possible, please let me know if there is anything I can do to help.
Beta Was this translation helpful? Give feedback.
All reactions