- **status**: review --> fixed
- **Comment**:
default(4.7):
changeset: 6877:37d9c2682da4
user: Hung Nguyen <[email protected]>
date: Wed Sep 09 11:33:17 2015 +0700
summary: imm: Add OPENSAF_IMM_FLAG_PRT47_ALLOW value for noStdFlags [#1471]
changeset: 6878:6413f5f3daa9
user: Hung Nguyen <[email protected]>
date: Wed Sep 09 19:31:45 2015 +0700
summary: imm: Introduce SA_IMM_ATTR_DEFAULT_REMOVED flag [#1471]
changeset: 6879:5030325050fd
user: Hung Nguyen <[email protected]>
date: Wed Sep 09 23:07:11 2015 +0700
summary: imm: Allow to remove default values as part of schema change
[#1471]
changeset: 6880:3ff40eb08c3c
user: Hung Nguyen <[email protected]>
date: Wed Sep 09 23:13:09 2015 +0700
summary: imm: Add support of default value removal to IMM tools [#1471]
changeset: 6881:b2854683c51c
tag: tip
user: Hung Nguyen <[email protected]>
date: Fri Sep 11 15:54:27 2015 +0700
summary: imm: Add test cases for default value removal [#1471]
---
** [tickets:#1471] imm: Add attribute def flag SA_IMM_ATTR_DEFAULT_REMOVED**
**Status:** fixed
**Milestone:** 4.7.FC
**Created:** Tue Sep 08, 2015 07:07 AM UTC by Zoran Milinkovic
**Last Updated:** Thu Sep 10, 2015 02:30 PM UTC
**Owner:** Hung Nguyen
One way of allowing the removal of a default from an attribute as part of a
schema change,
To be done in a controlled way would be to introduce a new SA_IMM_ATTR flag.
We could name it SA_IMM_ATTR_DEFAULT_REMOVED.
An upgrade that intended to remove a default value would have to set this flag,
for this to be accepted.
The falg would be kept after the removal of the default.
When an object-create (ccb or rt) occurs on an attribute with this flag set and
no value is provided for the attribute, then
This would be allowed (since there is no default) but a LOG_Notice message
would be written to the syslog simply stating
that the attribute X has a removed default and the attribute will have the
empty value.
This is an improvement on simply allowing blind removal of a default.
It reduces the problem that some client (program or human) that is creating an
instance of that class and is “used to” relying
on a default value for some attribute in that class gets into trouble. Things
would not work as expected functionally with
or without this flag so there is still a potential backwards compatibility
problem, but at least now it is easy to spot/track down
why the problem occurred in the syslog.
In addition, simply forcing the class developer doing the default removal to
explicitly set this flag, increases the chances that
The class developer will actually read the documentation once (!) and actually
maybe give some actual thought to the
possible not intended effects of the removal of the default.
Its not a perfect solution.
But it is better than just silently allowing non backwards compatible changes.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
