Ok, so best would probably be, to include add the decorator definitions to the trunk, since they don't interfere with anything, maybe without the WikiPage adjustments in delete and save. And then the new db functionality, like my rename stuff, can start using it, so we can get experience.
Attached is a diff, that just contains the decorators. So either apply this patch, or the one in the mail before with the changed WikiPage. Either way, some conclusion would be nice, so it's clear how to proceed. Regards Jan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
transaction_decorators.diff
Description: Binary data
On 14.10.2009, at 22:57, Remy Blank wrote: > Jan Schukat wrote: >> If this proposal gets accepted, I would start converting all code to >> use the new scheme, as I have stated before. > > I wouldn't convert all database writes to the new scheme in one big > patch. Instead, I would rather introduce it with new code (IIRC, you > wanted to work on wiki page renames) and get familiar with it, maybe > refine the scheme somewhat with the experience gained, and only then, > transition old code progressively. > > Converting all writes at the same time sounds like a good way to > introduce subtle bugs all over the code. Instead, if the new > functionality is initially confined to a small section of code, the > potential damage should be confined as well. > > -- Remy >
