Issue 2255: Proposal for persistent valuetypes (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Here is my proposal for how to solve the persistent valuetype problem. It allows valuetypes to be used for PSS with getter and setter access to the data, without changing the OBV Java language bindings or adding new keywords or pragmas to IDL. Any additions to IDL that may be desirable for improved functionality (e.g, query and finder support) could be designed jointly by the components submission group and the PSS group as part of some future RTF activity. The proposal is very simple. It is that persistent valuetypes must be abstract valuetypes with attributes. The attributes would be used to specify the persistent state of the object. Resolution: closed, no action Revised Text: Actions taken: December 15, 1998: received issue June 4, 1999: closed issue Discussion: Persistent valuetypes are part of a proposed submission to the PSS RFP which has not yet been adopted. If and when such a submission is adopted as an OMG specification, it MAY be appropriate to resubmit this, or a similar issue. Until then, even the filing of this issue is premature at best. Revised Text: Actions taken: Close, no action. End of Annotations:===== Return-Path: Date: Mon, 14 Dec 1998 23:38:33 +0000 From: Simon Nash Organization: IBM To: java-rtf@omg.org, obv-rtf@omg.org Subject: Proposal for persistent valuetypes Here is my proposal for how to solve the persistent valuetype problem. It allows valuetypes to be used for PSS with getter and setter access to the data, without changing the OBV Java language bindings or adding new keywords or pragmas to IDL. Any additions to IDL that may be desirable for improved functionality (e.g, query and finder support) could be designed jointly by the components submission group and the PSS group as part of some future RTF activity. The proposal is very simple. It is that persistent valuetypes must be abstract valuetypes with attributes. The attributes would be used to specify the persistent state of the object. For example, we could have: abstract valuetype foo { attribute string name; attribute long serial; }; custom valuetype pfoo: foo { }; Here foo contains the state definition of the persistent valuetype. This is the abstract type used by other IDL definitions to refer to this persistent valuetype. pfoo is used on the server to provide a persistent implementation of foo. In this example, it is declared custom so that it can control its marshalling and demarshalling. For example, it can refuse to allow itself to be marshalled if the type is only meaningful on the server side. We could go further and declare a transient subtype of foo: valuetype tfoo: foo { private string name; private long serial; }; The fields can be either private or public. Having the tfoo type allows instances of foo to be passed to a client that doesn't have a pfoo implementation. This allows persistence to be supported using getters and setters. A future extension could allow them to be supported using direct field access from Java. That could easily be added to this proposal by relaxing the requirement that persistent valuetypes be abstract. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Return-Path: Date: Tue, 15 Dec 1998 12:16:56 -0500 From: Bernard Normier Organization: IONA Technologies To: java-rtf@omg.org, obv-rtf@omg.org Subject: Re: Proposal for persistent valuetypes References: <36767CBD.EEBB13A4@iona.com> Simon, There are a number of flaws in your proposal: (1) Your values cannot be passed by value If you pass by value a pfoo, the receiving context will need a pfoo implementation; similarly if you pass by value a tfoo, the receiving context will need a tfoo implementation. However, the only interesting scenario is with a pfoo impl in one context and a tfoo in another one! (2) You are extending valuetypes Even if it is possible to define data members with the same names as inherited attributes (which I doubt), the spec does not say that such data members are used to provide AN implementation for these attributes. (3) It's particularly inefficient in C++ In C++, getters return copies -- if each time you access a big string or a blob which is part of the state of your persistent value, the implementation makes a copy, it's going to be real slow... (4) The semantics of attributes is not to describe state 'attribute' is just a short-hand notation for a pair of getter and setter. The *marshalable* state of a valuetype is described using data members; it seems logic to also use data members to describe the persistent state of a value, rather than attributes. (5) abstract values do not have init operations init operations (i.e. factories) are essential for persistent implementations of valuetypes. Cheers, Bernard Simon Nash wrote: > > Here is my proposal for how to solve the persistent valuetype > problem. > It allows valuetypes to be used for PSS with getter and setter > access to the data, without changing the OBV Java language bindings > or > adding new keywords or pragmas to IDL. Any additions to IDL that > may > be desirable for improved functionality (e.g, query and finder > support) > could be designed jointly by the components submission group and the > PSS group as part of some future RTF activity. > > The proposal is very simple. It is that persistent valuetypes > must be abstract valuetypes with attributes. The attributes would > be used to specify the persistent state of the object. > > For example, we could have: > > abstract valuetype foo { > attribute string name; > attribute long serial; > }; > > custom valuetype pfoo: foo { }; > > Here foo contains the state definition of the persistent valuetype. > This is the abstract type used by other IDL definitions to refer to > this persistent valuetype. pfoo is used on the server to provide a > persistent implementation of foo. In this example, it is declared > custom so that it can control its marshalling and demarshalling. > For example, it can refuse to allow itself to be marshalled if the > type is only meaningful on the server side. > > We could go further and declare a transient subtype of foo: > > valuetype tfoo: foo { > private string name; > private long serial; > }; > > The fields can be either private or public. Having the tfoo type > allows instances of foo to be passed to a client that doesn't have > a pfoo implementation. > > This allows persistence to be supported using getters and setters. > A future extension could allow them to be supported using direct > field access from Java. That could easily be added to this proposal > by relaxing the requirement that persistent valuetypes be abstract. > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Return-Path: From: jrhyne@us.ibm.com X-Lotus-FromDomain: IBMUS To: Bernard Normier cc: java-rtf@omg.org, obv-rtf@omg.org Date: Tue, 15 Dec 1998 16:57:31 -0500 Subject: Re: Proposal for persistent valuetypes Content-Disposition: inline Bernard, I continue to think this is a good idea. See below. Jim Jim Rhyne, STSM, Component Broker Tool Architect jrhyne@us.ibm.com, 416 448 4383 IBM Canada Ltd. 2G/846/1150/TOR 1150 Eglinton Ave. E., Toronto, Ont. M3C 1H7 CANADA Bernard Normier on 12/15/98 12:16:56 PM To: java-rtf@omg.org, obv-rtf@omg.org cc: (bcc: Jim Rhyne/Somers/IBM) Subject: Re: Proposal for persistent valuetypes Simon, There are a number of flaws in your proposal: (1) Your values cannot be passed by value If you pass by value a pfoo, the receiving context will need a pfoo implementation; similarly if you pass by value a tfoo, the receiving context will need a tfoo implementation. However, the only interesting scenario is with a pfoo impl in one context and a tfoo in another one! >> We do not think it necessary or even appropriate to pass persistent >> values as ordinary valuetypes. While is is possible to convert a persistent >> valuetype into an ordinary valuetype, this is useful only for small >> objects. Much of the time, the developer will declare a set of valuetypes >> each of which returns an interesting segment of the persistent data >> and some non-persistent data in addition. Converting the other way >> cannot be done without custom code except in the simplest cases. >> My opinion is that this is not a requirement. (2) You are extending valuetypes Even if it is possible to define data members with the same names as inherited attributes (which I doubt), the spec does not say that such data members are used to provide AN implementation for these attributes. >> I do not think is it necessary to define concrete datatypes the way >> Simon has. The same problem exists in C++ and folks have been using >> naming conventions to avoid collisions between the public accessors >> and the private state variables for years. (3) It's particularly inefficient in C++ In C++, getters return copies -- if each time you access a big string or a blob which is part of the state of your persistent value, the implementation makes a copy, it's going to be real slow... >> I would not access BLOBs in this way. Most everyone uses cursors >> to access BLOBs. It is difficult to avoid making copies of strings >> even when programming in C++. One generally has to wrap the string >> in some sort of class and pass around references to the class. Even >> then if anyone wants to muck with the bits, they work with a copy. >> The thing which would be nice to avoid is having to make copies >> in order to do string comparisons. This is easy to do in C++ because >> of operator overloading, but not easy to do in IDL which defines >> no builtin operators on strings. Maybe we should fix this because >> IDL strings are a pain whether they are used in persistent valuetypes >> or not. (4) The semantics of attributes is not to describe state 'attribute' is just a short-hand notation for a pair of getter and setter. The *marshalable* state of a valuetype is described using data members; it seems logic to also use data members to describe the persistent state of a value, rather than attributes. >> I do not agree with your logic which depends on the assumption >> that persistent values must be marshallable. This is a repeat >> of point (1). (5) abstract values do not have init operations init operations (i.e. factories) are essential for persistent implementations of valuetypes. >> The init operations on valuetypes do not come close to supplying the >> function that is needed for persistent valuetype factories. There >> are no primary or secondary key finders. There is no place to put >> operations which corredpons to mass updates or deletes in SQL 92. >> There is no place to put ADT methods, ... >> In your proposal, you added a few of these functions hidden in the >> language binding. This is not so good because the container must have >> special code to deal with the differences between C++, Java, COBOL, ... >> At least if these operations are specified in locality constrained IDL, >> the container could invoke them in a standard way and rely on the >> ORB services to map them to the language binding. >> I think for persistence we will need REAL factories with real >> interfaces - the simple init specification on concrete valuetypes >> is not powerful enough. Cheers, Bernard Simon Nash wrote: > > Here is my proposal for how to solve the persistent valuetype problem. > It allows valuetypes to be used for PSS with getter and setter > access to the data, without changing the OBV Java language bindings or > adding new keywords or pragmas to IDL. Any additions to IDL that may > be desirable for improved functionality (e.g, query and finder support) > could be designed jointly by the components submission group and the > PSS group as part of some future RTF activity. > > The proposal is very simple. It is that persistent valuetypes > must be abstract valuetypes with attributes. The attributes would > be used to specify the persistent state of the object. > > For example, we could have: > > abstract valuetype foo { > attribute string name; > attribute long serial; > }; > > custom valuetype pfoo: foo { }; > > Here foo contains the state definition of the persistent valuetype. > This is the abstract type used by other IDL definitions to refer to > this persistent valuetype. pfoo is used on the server to provide a > persistent implementation of foo. In this example, it is declared > custom so that it can control its marshalling and demarshalling. > For example, it can refuse to allow itself to be marshalled if the > type is only meaningful on the server side. > > We could go further and declare a transient subtype of foo: > > valuetype tfoo: foo { > private string name; > private long serial; > }; > > The fields can be either private or public. Having the tfoo type > allows instances of foo to be passed to a client that doesn't have > a pfoo implementation. > > This allows persistence to be supported using getters and setters. > A future extension could allow them to be supported using direct > field access from Java. That could easily be added to this proposal > by relaxing the requirement that persistent valuetypes be abstract. > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb