[jira] [Commented] (RIVER-130) JavaSpaces spec is silent on schema evolution

["Peter Firmstone (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RIVER-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043274#comment-15043274 ] 

Peter Firmstone commented on RIVER-130:
---------------------------------------

I brought up this issue again recently on the dev list, some developers responded that Entry's should not change, thus should not evolve after deployment.

Interfaces used to be similar, but now they have default methods.  Serialization supports evolution.  It may be easier to document that Entry's should not evolve.  

At some point the project needs to decide to update the spec, rather than remain silent.

> JavaSpaces spec is silent on schema evolution
> ---------------------------------------------
>
>                 Key: RIVER-130
>                 URL: https://issues.apache.org/jira/browse/RIVER-130
>             Project: River
>          Issue Type: Improvement
>          Components: net_jini_space
>    Affects Versions: jtsk_1.0
>            Reporter: John McClain
>            Priority: Minor
>
> Bugtraq ID [4256312|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4256312]
> User write entries of class {{Foo}}, modifies the class {{Foo}} (adding fields say) and then write more entries....should anything reasonable happen?  At the very least we should put verbiage in the spec saying that the results are undefined.
> Comments:
> We might also want to consider throwing an exception so that client program is notified of this condition
> An intresing example of this problem in real life was the removal of the static
> serVerID from Serializable between 1.2 and 1.2.2.  This caused problems because
> this made Entries from 1.2 VM have a different number of field as those from 1.2.2 VMs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)