helmut-vFAe+i1/wJJY/zfsw0qs4Ztpy8Vr/[email protected] writes: > In Rucksack e.g., the begin-transaction return a transaction, which is used > by commit and rollback. If a store is opened when the application starts, > weblocks api allows only one active transaction per store, as store is > the only parameter.
Look at svg's weblocks-clsql changes. > It would be nice, to add the transaction as a parameter to commit and > rollback, and as the return value of begin-transaction. I think this is a detail that should be handled by the store backend using repeatable per-thread pools, not expanding the API for something that most backends won't use. If you don't want to do this, you can always save it yourself by answering T from use-dynamic-transaction-p and implementing dynamic-transaction directly. > And perhaps a with-transaction macro for convenience. A webapp oughtn't ever use this. If you really need it, muffle warnings and call dynamic-transaction. > B) The persist-object is called with an instance, > which should be made persistent. If the > make-instance could be done in the persist-object method, > this would save copying and code (at least in rucksack :-) Except that we always make the instance way before persisting it. I've found that to be so even when calling persist-object myself. Can you show me why this would make store usage simpler? -- I write stuff at http://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 -~----------~----~----~----~------~----~------~--~---
