Goals
Have the ability to lock objects/records.
The isolation part of the ACID test is addressed by locking of objects (in most cases one or more rows of data) until the associated transactions are completed. The locking of objects stops all other processes from being able to change these objects until the lock is removed.
Currently in a multi-user situation, a Realm object can be viewed by one user and deleted by another. There is no mechanic that prevents deleting an object that is 'in use' or even knowing what the status of that object is before attempting a transaction.
Expected Results
I would imagine the API being something like this:
let personResults = realm.objects(PersonClass.self).filter("is_available == true")
personResults.setLock(withStatus: .readOnly) //sets all person objects that are available to readOnly.
If another user wants to delete those person objects, they could obtain the lock status before attempting delete:
let lockStatus = personResults.lockStatus //or realm_object.lockStatus
switch lockStatus {
case .readOnly:
case .writeOnly:
case .noLock
}
or if the object is readOnly, the delete attempt would return an error instead/in addition to being able to obtain it's status. I suggest the proactive approach of getting the status before deleting instead of reactive.
Realizing the server is not updated until a write transactions completes, the status could be done with a write, or perhaps the object function have it's own write.
Some have suggested manually adding a isLocked property to an object to obtain a similar functionality but that fails if for example, the client disconnects; there would be no way to 'reset' that lock status.
There would be additional benefit to adding an event observer to the server or enabling Server Functions that could take action when say, a user disconnects. Similar to the onDisconnect function in Firebase.
Goals
Have the ability to lock objects/records.
Currently in a multi-user situation, a Realm object can be viewed by one user and deleted by another. There is no mechanic that prevents deleting an object that is 'in use' or even knowing what the status of that object is before attempting a transaction.
Expected Results
I would imagine the API being something like this:
If another user wants to delete those person objects, they could obtain the lock status before attempting delete:
or if the object is readOnly, the delete attempt would return an error instead/in addition to being able to obtain it's status. I suggest the proactive approach of getting the status before deleting instead of reactive.
Realizing the server is not updated until a write transactions completes, the status could be done with a write, or perhaps the object function have it's own write.
Some have suggested manually adding a isLocked property to an object to obtain a similar functionality but that fails if for example, the client disconnects; there would be no way to 'reset' that lock status.
There would be additional benefit to adding an event observer to the server or enabling Server Functions that could take action when say, a user disconnects. Similar to the onDisconnect function in Firebase.