Tombstone classified as root object about neofs-node HOT 8 CLOSED

I propose to implicitly add $Object:objectType=REGULAR to $Object:ROOT filter then and reflect it in api doc and leave other filters as-is.

from neofs-node.

Well, physically tombstones are root objects. Is there a requirement to exclude tombstones from such a search?

from neofs-node.

Well, physically tombstones are root objects. Is there a requirement to exclude tombstones from such a search?

Yes, in nspcc-dev/neofs-api-go#163 we discussed leaf and root objects as a system and user scope. Tombstone is an internal implementation detail and should not be seen in user scope, therefore tombstone is not a root object. However it is a physically stored object, that can be migrated and replicated, so it is a leaf.

from neofs-node.

Well, physically tombstones are root objects. Is there a requirement to exclude tombstones from such a search?

Yes, in nspcc-dev/neofs-api-go#163 we discussed leaf and root objects as a system and user scope. Tombstone is an internal implementation detail and should not be seen in user scope, therefore tombstone is not a root object. However it is a physically stored object, that can be migrated and replicated, so it is a leaf.

According to neofs-api tombstones match root filter. Is it a bug in API?

from neofs-node.

According to neofs-api tombstones match root filter. Is it a bug in API?

I would like to say yes, but maybe there are different opinions on that. Neofs-api contains implementation details, but it lacks the meaning behind root and leaf objects (as for me, they should represent user and system scopes)

from neofs-node.

What do you think @realloc?

from neofs-node.

I think Tombstones are a special type of objects, as indicated in ObjectType. Object Search operations should work with Regular objects by default. If there is need to search for Tombstones or Storage Groups, the one may use $Object:objectType key.

Tombstone has a list of engraved objects in it's payload, just like Storage Group does. It doesn't participate in split hierarchy directly, it doesn't have split headers and because of that it should not be treated as leaf or root object. I propose to exclude Tombstones and Storage Groups from regular search and reflect that behaviour in documentation.

from neofs-node.

I think Tombstones are a special type of objects, as indicated in ObjectType. Object Search operations should work with Regular objects by default. If there is need to search for Tombstones or Storage Groups, the one may use $Object:objectType key.

Tombstone has a list of engraved objects in it's payload, just like Storage Group does. It doesn't participate in split hierarchy directly, it doesn't have split headers and because of that it should not be treated as leaf or root object. I propose to exclude Tombstones and Storage Groups from regular search and reflect that behaviour in documentation.

While I agree that only regular objects should be treated as root object, I cannot agree about leafs. Leafs are designed to return physically stored object. It is useful for system operations like replication because storage groups, tombstone and regular objects should be treated equally.

from neofs-node.