Tuscany
  1. Tuscany
  2. TUSCANY-761

Support the ability to unregister all the SDO Types in a namespace

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Java-SCA-M2
    • Fix Version/s: Java-SDO-Next
    • Labels:
      None

      Description

      Add an SDO lifecycle metadata Tuscany extension to unregister all the SDO Types in a namespace. The suggested method is SDOUtil.unregisterTypes(TypeHelper typeHelper, String namespace).

        Activity

        Hide
        Yang ZHONG added a comment -

        Is anyone working on this? If no, I can give a try.

        Show
        Yang ZHONG added a comment - Is anyone working on this? If no, I can give a try.
        Hide
        Brandon Werner added a comment -

        I'll look in to this too as my first work on this project, since it's something I'd like for what I'm working on

        Show
        Brandon Werner added a comment - I'll look in to this too as my first work on this project, since it's something I'd like for what I'm working on
        Hide
        Kelvin Goodson added a comment -

        This requirement could be reviewed in the light of the introduction of HelperContext. It's not clear what we might break by implementing this explict removal, but if the compartmentalization that HelperContext provides solves the use case that drove the requirement then we might elect not to do this.

        Show
        Kelvin Goodson added a comment - This requirement could be reviewed in the light of the introduction of HelperContext. It's not clear what we might break by implementing this explict removal, but if the compartmentalization that HelperContext provides solves the use case that drove the requirement then we might elect not to do this.
        Hide
        Ron Gavlin added a comment -

        Kelvin, please elaborate on your previous comment in light of the following:

        Say I have a a TypeHelper with numerous, large and small namespaces registered. Then I need to "unregister" one of the small namespaces. I suspect it will be much more efficient to "unregister" the small namespace in the existing TypeHelper than to create a new TypeHelper and to re-register all the namespaces (minus 1) in the new TypeHelper.

        Show
        Ron Gavlin added a comment - Kelvin, please elaborate on your previous comment in light of the following: Say I have a a TypeHelper with numerous, large and small namespaces registered. Then I need to "unregister" one of the small namespaces. I suspect it will be much more efficient to "unregister" the small namespace in the existing TypeHelper than to create a new TypeHelper and to re-register all the namespaces (minus 1) in the new TypeHelper.
        Hide
        Frank Budinsky added a comment -

        Ron, for the scenario you describe, this feature would be simpler. One concern with having an unregister method is what would happen if a user unregisters a namespace which other packages (that are not unregistered) have a dependency on. Would you expect that this feature would automatically unregister those packages as well or just leaves it up to the users to make sure that they don't put the registry into a corrupt state?

        Show
        Frank Budinsky added a comment - Ron, for the scenario you describe, this feature would be simpler. One concern with having an unregister method is what would happen if a user unregisters a namespace which other packages (that are not unregistered) have a dependency on. Would you expect that this feature would automatically unregister those packages as well or just leaves it up to the users to make sure that they don't put the registry into a corrupt state?
        Hide
        Ron Gavlin added a comment -

        Frank, I would not expect the runtime to manage dependencies in this case. Rather, it would be up to users to make sure they don't corrupt the registry. As Kelvin mentioned earlier, the introduction of HelperContext now provides a safe alternative to this "unregistration" in case users want to be sure they don't corrupt the registry.

        Show
        Ron Gavlin added a comment - Frank, I would not expect the runtime to manage dependencies in this case. Rather, it would be up to users to make sure they don't corrupt the registry. As Kelvin mentioned earlier, the introduction of HelperContext now provides a safe alternative to this "unregistration" in case users want to be sure they don't corrupt the registry.
        Hide
        Amita Vadhavkar added a comment -

        There is some discussion on Feb4,5,6 2008 IRCs, - here is the summary - what is the memory cost of having to init number of HelperContexts?
        Each one has at constrcution an instance of all HElpers that require to manage their own state – i.e. not CopyHelper or
        EqualityHelper, but all the others . The state of each of these helpers is not large until you start registering types
        so i think there would only be significant cost if there were duplication in storage of metadata across typehelpers
        so the problem with multiple HelperContexts would be when loading XML

        Also, please let know if the issue mentioned in the JIRA still a requirement.

        Show
        Amita Vadhavkar added a comment - There is some discussion on Feb4,5,6 2008 IRCs, - here is the summary - what is the memory cost of having to init number of HelperContexts? Each one has at constrcution an instance of all HElpers that require to manage their own state – i.e. not CopyHelper or EqualityHelper, but all the others . The state of each of these helpers is not large until you start registering types so i think there would only be significant cost if there were duplication in storage of metadata across typehelpers so the problem with multiple HelperContexts would be when loading XML Also, please let know if the issue mentioned in the JIRA still a requirement.
        Hide
        Ron Gavlin added a comment -

        Yes, this is still a requirement. Again, my concern is the overhead required to register types in the typeHelper every time I need to remove a single namespace from the typeHelper. The memory cost is not significant to me, it is the cpu cost of re-registering types in a new typeHelper.

        Show
        Ron Gavlin added a comment - Yes, this is still a requirement. Again, my concern is the overhead required to register types in the typeHelper every time I need to remove a single namespace from the typeHelper. The memory cost is not significant to me, it is the cpu cost of re-registering types in a new typeHelper.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ron Gavlin
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development