Hi Amita, I'm not aware of anyone planning to fix 761. There were a couple of possible approaches, either or both of which could be developed. Ron Gavlin painted a scenario in the JIRA where dropping of individual types from a namespace would be the right thing to do.
There's also discussion of dropping whole HelperContexts, which raises again the question of how we might establish dependencies between HelperContexts. This could be a useful discussion to open up and get a design in place for. As to your scenario of changing a type, it would be good to check through the scenarios you envisage. The current Tuscany API implementations permit alteration of Types after they have been used, whereas the SDO API implementations freeze the types at creation time. Depending on which scenarios we support the user would have to take care to ensure certain preconditions before calling a method such as createOrReplaceType(). My guess is that this method would end up as a simple convenience method, involving calls to the type dropping and creation methods. Here are some attributes of scenarios that we might want to consider in order to see which combinations we support/exclude. Note, exclusion doesn't necessarily imply enforcement by the SDO implementation and this kind of area clearly contains hazards - a Type is removed from a scope (HelperContext) when no DataObjects reference it - a Type is removed from a scope while still referenced by DataObjects - a Type is replaced in a scope while DataObjects still reference the displaced Type instance - a Type is replaced in a scope only when no DataObjects reference the displaced Type instance - Properties are added to a Type after instances of the Type have been created - an instance of a Type is otherwise updated when still referenced by DataObjects (expand ...) - multiple instances of HelperContexts are used to manage multiple instances of Types with the same name and in the same namespace Kelvin. On 30/08/2007, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > What is the plan for JIRA-761(Support the ability to unregister all the SDO > Types in a namespace) > > Also, I am just trying to understand that in a condition where some Type is > defined in > using SDOUtil.createType() and later some attributes of it need to change > during > the same runtime invocation. So user needs SDOUtil.createOrReplaceType() - > how this can be done? > > Regards, > Amita > > On 8/29/07, Fuhwei Lwo <[EMAIL PROTECTED]> wrote: > > > > Hi Kelvin, > > > > Based on my observation on opened JIRAs, I agree we definitely should pay > > attention to the first two items you listed below - test generated static > > SDO APIs and multi-threaded scenario more easily. > > > > I did some investigation on GroboUtils for multi-thread testing and still > > couldn't find any remote repository hosting the tool so we may need to host > > the tool ourselves or find an alternative. What do you think? > > > > Fuhwei > > > > kelvin goodson <[EMAIL PROTECTED]> wrote: Having released > > 1.0-incubating, what are the priorities for SDO Java now. > > > > I'm just catching up on reading the lists having taken a break. The > > major things I had in mind before going away were to > > > > - rearrange the project structure to permit generation of java classes > > during maven tests (TUSCANY-1393) > > > > - add multi-threaded test cases (TUSCANY-1182) > > > > - for the first of the above, while we are in project reorganisation > > mode it's probably worth fixing TUSCANY-257 to separate out the Java 5 > > dependencies > > > > - It would be great to get some improvement our web pages; and getting > > some good user documentation together would be really helpful. > > > > My brain hasn't completely returned from vacation, so I've probably > > missed out some obvious things, so please chip in with your opinions, > > needs and inspirational ideas! > > > > Kelvin. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
