[sdo] [SDO-14]: Service Modification of Read Only Properties(Service-level Programming Interface)

[Radu Preotiuc-Pietro <radup@bea.com>]

Steve Brodsky:

On the appropriate helper interface, add:

void enforceReadOnly(DataObject dataObject);
void disableReadOnly(DataObject dataObject);

void enforceReadOnly(List<DataObject> dataObject);
void disableReadOnly(List<DataObject> dataObject);

boolean isReadOnlyEnforced(DataObject dataObject);

This will turn read only enforecement on and off for one or a list of
DataObjects. Can check the state of a single DataObject. The default for
new DataObjects is enforceReadOnly.


James Taylor:

We are in support of proposal #3 for 2.1: Specification of initial
values in some DataObject constructor (e.g. on DataFactory), because it
provides the missing functionality to set the value of a read-only
property from the client. We feel that adding an SPI is too big a
deviation from the current spec to be included in a point release (2.1).


Steve Brodsky:

The constructor approach (#3) could be addressed by adding to
DataFactory

create(Type type, Object[] initialValue);
create(Class interfaceClass, Object[] initialValue);
create(String uri, String typeName, Object[] initialValue);

where the index of the initial values is the same Property index in
Type.getProperties().

This proposal would not address read-only open content, but that does
not seem to be an important use case.


Henning Blohm:

We (SAP) would rather prefer the helper interface (see Steve's comment),
since we expect the case where the DAS require subsequent access to
read-only properties may occur frequently:

      * specification of primary key (example above)
      * fixing computed properties upon service call (e.g. sum of order
        items)

We think that the read-only contract is to the consumer from the
producer and should not apply to the producer (i.e. the DAS) at all.


Frank Budinsky:

I vote for proposal #1 (maybe we can come up with nicer names though 

Proposal 2 is the same as 1, but not as clean.

Proposal 3 doesn't solve the problem completely. The doc says this:
"Values may change due to other factors, such as services operating on
DataObjects." So, readOnly properties need to be modifiable, some how -
not just initializable.

Proposal 4 and 5 require additional state in every DataObject instance.


Steve Brodsky:

If this is proposed for 2.1, please update - currently the target
release is unspecified, so by default I am proposing 3.0.


Steve Brodsky:

The group would like this for 2.1

Frank Budinsky:

If I remember correctly, the last time we discussed this issue in a
call, we were starting to lean towards option #2.

I was thinking that maybe instead of trying to define a new SPI
interface we should just use an existing interface for the new set
method. It seems to me, that readOnly isn't really a security feature,
but more of a clean way to define the client API. That is, readonly
properties should not be settable through the client interface
(DataObject). So, any alternate API to do it, would be acceptable.

If the above sounds reasonable, maybe a good way to support this is by
adding a setValue() method to the Property interface:

/**

      * Set the value of this Property in the specified DataObject to
        the specified value. This method behaves the same as
      * DataObject.set(Property property, Object value), but can also be
        used to set readOnly properties.
      * This method would typically be used by a DAS to set readOnly
        properties in a DataObject before passing it to a client.
      * @param dataObject the object in which to set the value.
      * @param value the new value for the property.
        */
        void setValue(DataObject dataObject, Object value);

This seems like kind of a "back door" (backward, anyway) way to do this.

Thoughts?


Frank Budinsky:

One more thought on this issue. I've been asked if there is a
lower-level set() API that a deserializer, for example, could call. Some
set() callers can be assumed to be passing valid/consistent data to the
set methods, so it may be possible to avoid some of the checking that an
implementation may be doing in DataObject.set(). So, generalizing the
above method a bit, maybe we could say something like this:

"This method behaves the same as DataObject.set(Property property,
Object value), but can also be used to set readOnly properties. Callers
to this method are assumed to be passing valid/consistent arguments and
therefore an Implementation may perform less checking then in the
general purpose DataObject.set() method."


Ron Barack:

We would still prefer the helper interface. But given the time
constraints, I no longer think this is resolvable in the 2.1 timeframe,
and propose moving to 3.0



Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.