Do not store system data in raw key-value attributes #104

New issue

Closed

opened 2025-12-28 18:12:34 +00:00 by sami · 2 comments

sami commented

2025-12-28 18:12:34 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (Aug 31, 2023).

NeoFS protocol contains several messages with raw string k-v attributes. These fields is dedicated for the user- or application-specific stuff and the system almost always not interested in them. At the same time, there are system attributes like __NEOFS__EXPIRATION_EPOCH. This is very (very) bad approach cuz it raises a lot of duality issues.

The most interesting case is nspcc-dev/neofs-api@7ae1a7438b/object/service.proto (L527) where user attributes are mixed with object headers and even logical properties. For example, expiration attribute is a regular attribute in SEARCH context, and the system overall.

Proposal

Add new field for each system attribute
Never ever add system data to raw attributes

Sad thing that we already have attributes like __NEOFS__EXPIRATION_EPOCH that must be supported until next major version.

Originally created by @cthulhu-rider on GitHub (Aug 31, 2023). NeoFS protocol contains several messages with raw string k-v attributes. These fields is dedicated for the user- or application-specific stuff and the system almost always not interested in them. At the same time, there are system attributes like `__NEOFS__EXPIRATION_EPOCH`. This is very (very) bad approach cuz it raises a lot of duality issues. The most interesting case is https://github.com/nspcc-dev/neofs-api/blob/7ae1a7438b19fc4ca32c451db67de170edb539a7/object/service.proto#L527 where user attributes are mixed with object headers and even logical properties. For example, expiration attribute is a regular attribute in SEARCH context, and the system overall. ## Proposal 1. Add new field for each system attribute 2. Never ever add system data to raw attributes Sad thing that we already have attributes like `__NEOFS__EXPIRATION_EPOCH` that must be supported until next major version.

sami

2025-12-28 18:12:34 +00:00

closed this issue
added the
discussion

U4

I3

S1
labels

sami commented

2025-12-28 18:12:34 +00:00

Author

Owner

@roman-khimov commented on GitHub (Aug 31, 2023):

expiration attribute is a regular attribute in SEARCH context, and the system overall.

There are good things about it too, it can be used in various attribute-related expressions just like any other attribute, not needing any specific logic.

Add new field for each system attribute

Which adds some overhead even when the attribute is not used.

supported until next major version.

No major version can help with old objects.

I don't think we can or even should change this. Frankly, it'd be easier to maintain the system if we had more attributes, like object creation epoch is completely useless right now, but we can't create an object without it. It also allows for more extensibility without object format changes.

@roman-khimov commented on GitHub (Aug 31, 2023): > expiration attribute is a regular attribute in SEARCH context, and the system overall. There are good things about it too, it can be used in various attribute-related expressions just like any other attribute, not needing any specific logic. > Add new field for each system attribute Which adds some overhead even when the attribute is not used. > supported until next major version. No major version can help with old objects. I don't think we can or even should change this. Frankly, it'd be easier to maintain the system if we had _more_ attributes, like object creation epoch is completely useless right now, but we can't create an object without it. It also allows for more extensibility without object format changes.

sami commented

2025-12-28 18:12:34 +00:00

Author

Owner

@roman-khimov commented on GitHub (Apr 3, 2024):

Not planned.

@roman-khimov commented on GitHub (Apr 3, 2024): Not planned.