You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "John McClain (JIRA)" <ji...@apache.org> on 2007/07/27 22:02:53 UTC
[jira] Created: (RIVER-130) JavaSpaces spec is silent on schema
evolution
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
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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-130) JavaSpaces spec is silent on schema
evolution
Posted by "John McClain (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John McClain updated RIVER-130:
-------------------------------
Priority: Minor (was: Major)
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.