>From my limited experience with Elephant here are some points: 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.
2. Persistence. Elephant persistence model is basically "always persist this object". I find myself in several situations where I have to create ephemeral objects that mimic the persistent objects because I don't want to persist them just yet - I want to persist the objects once the user commits to an action. This forces me to have a basically three classes: base, ephemeral (inherits from base) and Elephant persistent (also inherit from base). Then then I write a custom persist-object that specializes on the Elephant store and the ephemeral that does a copy onto a persistent object, this storing the final result. Incidentally, hence the reason two classes aren't enough, since inheriting from ephemeral to persistent directly also means the persistent object an 'ephemeral' by inheritance which is confusing and can duplicate objects accidentally. This isn't just a part of the transaction problem - you don't want to open transactions indefinitely, hence the need for ephemeral objects until the user decides to save - you then wrap saving multiple ephemeral objects into a single transaction. So, the current Elephant store has it's drawbacks. I'm going to have a closer look at the transactions in Elephant to see if the store can be rewritten to conform to what Weblocks expects. I am not sure if that can be done at this point, which may mean I may have to fallback on CLSQL (with per-thread connection pooling from svg). Yarek On Dec 24, 7:59 pm, Ian Eslick <[email protected]> wrote: > The action is dynamically wrapped by a with-transaction statement. As > Stephen says, the elephant transaction mechanism is not entirely > compatible with the assumptions in it. The with-transaction macro > presumes that a non-local exit is an abort and so aborts the entire > action transaction. I'm not certain it's still in dev, but I use a > post-action-redirect which simply adds a post-action hook to the > request hook that calls the redirect function after the transaction > has committed. > > Perhaps at some point we can revisit some of the Elephant store hacks > I had to implement to make it work with Weblocks assumptions about > persistent objects and see if there is a way to upgrade the Weblocks > built-in functionality to subsume/support all the various models. > > Ian > > On Dec 24, 2008, at 8:30 PM, Stephen Compall wrote: > > > > > Yarek Kowalik <[email protected]> writes: > >> The problem is that somehow 'redirect' causes the delete of the > >> elephant object to fail, as if the elephant transaction was canceled > >> (how do I check that this is indeed so?). Visually, the user is > >> simply > >> not logged out. Now, if I comment out the redirect, and do simply a > >> mark-dirty on the containing widget, the user is properly logged out > >> of site. > > > Elephant's elephant-transaction-hook doesn't reproduce all of the > > functionality allowed by store API and implemented in `action-txn- > > hook'. > > > This is why we haven't replaced the trio of transaction GFs with a > > dynamic-wind one: it would preclude cross-store features like the ones > > implemented by action-txn-hook. As I understand it, Elephant doesn't > > export sufficient functionality to implement the trio. > > > -- > > I write stuff athttp://failex.blogspot.com/now. But the post > > formatter and themes are terrible for sharing code, the primary > > content, so it might go away sooner or later. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
