Hi,

are there plans to support locking and/or more complete undo support in autocommit mode? Autocommit mode in theory is very nice to use, but the complete lack of locking and only very sporadic undo support make it hard to use in practice.

Cheers,

Henning

Hi!
Locking shouldn’t be a problem in autocommit mode, since rows may be locked only for the duration of a transaction. We could probably do something when editing starts and ends but we haven’t thought about that much yet. Do you have a specific case in mind?
Undo support is also somewhat difficult to work out with autocommit, because queries might have side effects that are difficult to predict on framework level. It would probably be possible to create transactions based on undo grouping also in autocommit mode but we haven’t thought of that much yet.

Regards,
Tuukka

The case for locking I have in mind is the following: The user browses a list of read-only entries, and to edit one, she opens a new window for the entry. While this window is open, I’d like the entry to be locked to prevent conflicts. I saw the lock-methods, but they are marked as internal at the moment, so I was hesitant to use them.

I made local undo work in my application work by creating and deleting objects via a helper object, which records the appropiate undo actions. Changes to an object are still recorded by BaseTen itself. If a BXDataseObject gets deallocated because of a remote deletion, I remove all local undo actions from the stack. This works more or less well with few concurrent users, which will probably be the case in the case of my app.

I also wanted to say Thank you for this framework, it fills the gap between CoreData and using raw SQL nicely! :)