PSS 1.0 NO IDEA Avatar
  1. OMG Issue

PSS — PSS storage model and associated object interactions unclear

  • Key: PSS-28
  • Legacy Issue Number: 4074
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    See the Persistent State Service specification, orbos/99-07-07, section
    5.2.2 (or thereabouts) and section 7.

    I am confused by the storage model "overview" given in section 5.2.2 and
    the more comprehensive treatment in the discussion of the PSDL grammar
    in section 7. The treatment of abstract storage types, homes, and their
    (concrete) implementations is inadequately mapped between the two,
    leading to very unclear semantics. My specific concerns:

    • It is explicitly stated in the text that types, homes, and their
      independent derivation lines are taken from a Java model. Why this
      explicit dependence on Java? Could the submitters not come up with a
      more generic model? Has anyone tried to map these concepts to
      Smalltalk, which doesn't have the same kinds of object representation
      and implementation difficulties as Java and C++? Even though I am a
      Smalltalk expert, my attempts at such a mapping on the proposed model
      have been less than exciting.
    • Although the keyword "abstract" was already defined, why are abstract
      storagetypes and storagehomes "abstract"? They certainly seem
      concrete enough to me, since I would expect that the definition is
      sufficient to generate code equivalent to a valuetype. This
      ambiguates both the general IDL concept of abstraction and concrete
      storagetypes in particular: in all other places abstract types
      represent non-instantiable objects that have no explicit state, and
      it is not at all clear how concrete storagetypes are more "concrete"
      than their abstract relatives.
    • The text indicates that each storagetype must have its own home. Is
      that abstract types, concrete types, or both? Why? Whatever
      happened to polymorphism? If I have multiple storagetypes with
      similar or compatible keying properties, why cannot they all be
      indexed or managed together? I should only require a different home
      if the behavior is different. Even if a language mapping [read that
      as "implementation"] should require such, please don't make that a
      general limitation of the entire model. This is a very useful
      service; let's not restrict its utility or expressive power by
      playing to language limitations.
    • I can understand that you want to keep factory, finder, and
      management behavior separate from storage object behavior, but has
      anyone actually articulated the reasons behind this? (This also
      affects the component model.) What are they? I can see several
      reasons for keeping the factory and finder operations with the
      storagetype, in the same way valuetypes specify factory operations.
      I am also concerned about the apparently artificial complexity
      introduced by requiring parallel derivations of storagetypes and
      storagehomes. Why not generate the homes automatically when needed?
    • Why are keys placed on the storagehome? It would seem more logical
      that you define the keys (as properties) of the storagetype and then
      optionally map those to indices in a datastore, catalog, or
      storagehome. Perhaps we should indicate that, for a particular
      storagetype, certain state members may participate in a key. Why
      isn't at least one key identified as a primary key? Why cannot I
      explicitly define some keys as unique leaving others as non-unique to
      form inverted indices?
    • The text indicates that a concrete storagetype "implements" one or
      more abstract storagetypes. What does this mean? How is this
      accomplished? What are the navigation paradigms, especially for
      multiple storagetypes? What interfaces are expected? This whole
      concept is too weakly specified, and the example in section 10 is too
      simple to explain multiple type implementation.
    • What is the purpose of a catalog and its limitation of singleton
      instances of storagehomes? I can think of reasons why I would want
      multiple instances of a particular storagehome, especially for
      configuration management in the datastores. Can one have multiple
      catalogs, and if so, how do you select one of them, since "by name"
      might not be the best keying property?
  • Reported: PSS 1.0b1 — Tue, 21 Nov 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:


  • Updated: Fri, 6 Mar 2015 20:58 GMT