> 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 -~----------~----~----~----~------~----~------~--~---
