Do you have any ideas about its implementation?
I think it should be sufficient to change the GetxxxxCacheKey functions where sources are possible. And, of course, the calls to these functions.
I would like to add your behaviour changing code to a next version.
If you have other patches hanging around that don't impact current default behaviour or correct bugs these can be done immediately. (But must be applied separately to enable their migration from testing branch to trunk)
Behaviour changes with small code impact can also be done to testing branch. Your problem is another kind of stuff (as we saw doing the patch in this thread)
Some other idea: maybe it would be nice to have a public 'GetXXXSource' metadata function call for every database object type having a source. This would allow people not wanting to fetch every source to get the source of a specific object. (This is an example of stuff that could be added immediately
)
So for now we could go in two directions.
1. I just wait with integrating and you just maintain your modifications when the svn testing branch changes. This will probably just give a problem at this moment. Normally the metadata functions don't change that much as they have done now.
2. You do (mostly copy) the changes again to a separate working copy, but step by step, adding the new columns and function parameters last. This way we can fix the existing bugs and add the source retrieval functions immediately (version 6.6) Once that's done the behaviour changing part can be done and must be maintained until after the 6.6 release.
Personally I prefer the second route, but as you're supposed to do the coding (sorry for that, but no time to do it myself), it's up to you.
Mark
(I've split your post from the other thread so we can discuss this without disturbing technobot)