> > 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? Yes, I agree that transactions should be handled in the backend. Most transactions are bind to the logic of data, unknown to widgets (e.g .rebooking). I'm not sure, if I catched on that store-api protocol at all: In the model part, I have a class employee. An instance is the result of a query form person, company, address, department, etc. tables. The employee would be shown in a gridtable/data/form. Now some data changes, which means the widget change/update the slots of the employee instance. And then for each updated instance persist-object is called, as a hint to update the tables of the e.g. sql database tables, which may result in a series of insert/delete/updates of the some tables. So the store-api is more an interface between the gui and the model data, or do I bark up the wrong tree? Helmut --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
