It appears that the Weblocks API store methods BEGIN-, COMMIT- and ROLLBACK-TRANSACTION could be implemented with Elephant's CONTROLLER- [START/COMMIT/ABORT]-TRANSACTION. But, just adding those in won't do: it's the interaction with the action hook transaction could be an issue.
Yarek On Dec 26, 10:43 pm, Yarek Kowalik <[email protected]> wrote: > > 1. Transactions. The current implementation of the Elephant store > > does not do transations in the sense that Weblocks expects them. The > > methods BEGIN-, COMMIT- and ROLLBACK-TRANSACTION don't do anything. > > You can very easily find yourself in an inconsistent state if you > > forget that fact: if you try to start a transaction in :pre-persist in > > the dataform with the expectation to commit in :on-success or rollback > > in :on-cancel, you'd be sorely mistaken someday. > > Actually, the dataform is not a good example, since in this case the > action of clicking on the OK button the form will be wrapped in a > transaction that was setup via the dyamic-action hook (see SETUP- > ELEPHANT-TRANSACTION_HOOKS) created on open-store. > > So, actually, as long as you do all object creations/updates during > the action, you're safe. Which means that anything more complex > requires creation of several ephemeral objects that get all committed > (copied to persistent objects) in one swell swoop during the action. > > This is actually a nice feature, but any other more complex user > interactions that require start of a transaction and committing in > separate actions is not currently supported. That's not the case with > CLSQL, which lets you do your own begin/commit/rollback (and > consequently allow you to shoot yourself in the foot to :)). CLSQL > and Elephant stores are two very different persistence models. > > One of the challenges I see with abstracting the various persistence > mechanisms as bonafide supported Welbocks stores is that this hides > the important details of how the persistence actually works for each > one. It gives a false sense of security, and can fool one into > thinking the web app is written well when in fact is written > incorrectly. > > I am not sure what to do about this. The whole concept of stores is > ingrained deeply into weblocks, and the use of store API is deeply > ingrained in the framework, but it seems clear to me that the stores > are a leaky abstraction, and are not to be taken lightly. I worry > that they are being taken too lightly right now. > > I think in the case of Elephant it would make sense to make start/ > commit/rollback transactions to throw back an error immediately, to > make it clear to the user that these are not implemente (but also > informing that transactions do exist around each action). > > Also, the notion of a transaction hook around an action is a useful > one and perhaps should be ported to other stores, perhaps disabled > with a proper key to open-store. > > Yarek --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
