Dear Sascha, Generally speaking it is a good idea to avoid using the comment character (#) in the attribute fields (descr in this case), unless you use it for a comment indeed. In your example I have the impression that # is intended to stand for "number". Best regards, Janos Zsako On 21/06/2022 11:17, Edward Shryane via db-wg wrote:

Hi Sascha,

This is intentional behaviour, any comment is not considered part of the attribute value.

If you only update a comment, the object is considered to be identical to what it was before (i.e. there has been no significant change).

The workaround as you mentioned is to change something else at the same time.

Regards Ed Shryane RIPE NCC

...

On 21 Jun 2022, at 10:11, Sascha E. Pollok via db-wg <db-wg@ripe.net> wrote:

Hi everyone,

I just tripped over something today which I have never noticed after >20 years of using the RIPE DB :-) It might be explained somewhere but I haven't found anything so here it is.

I am updating an inetnum object from:

descr: Testobject Ticket #12345 to descr: Testobject Ticket #123456

using Syncupdate. This results in a "No Operation" (Warning: Submitted object identical to database object). Is this intentional? It works if I remove the # and add it again in a second step. I assume it's something about it being interpreted as a comment but even if that's the case, I should still be able to update it.

Can someone enlighten me?

Thank you and best regards Sascha

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg

Hi Sascha,

On 27 Jun 2022, at 13:27, Sascha E. Pollok <sp+dbwg@iphh.net> wrote:

... @Ed: If this were a comment (it is not here but what was I thinking to use the # for anything else :-D) wouldn't this still be something someone could want to update? Let's say a peer's name in an aut-num object or similar? I would have expected that also comments should get the chance to be updated.

Not a big issue of course but still wondering why it was implemented that way.

The comparison logic ignores comments as it's not considered part of an attribute's value, i.e. it's not significant (it's only for humans to read as metadata). Because of that, if only a comment has changed in an update the object itself is considered identical and a NOOP is returned. Regards Ed Shryane RIPE NCC

Hi Gert,

On 28 Jun 2022, at 08:31, Gert Doering <gert@space.net> wrote:

Hi,

On Mon, Jun 27, 2022 at 01:47:23PM +0200, Edward Shryane via db-wg wrote:

...

The comparison logic ignores comments as it's not considered part of an attribute's value, i.e. it's not significant (it's only for humans to read as metadata).

I find that approach flawed. If I send you an update that differs in parts humans will find interesting to read, and that you are going to *store*, ignoring it as part of the "has anything changed" check will do no good, and create friction at times.

Ignoring bits that are *not stored* (like, whitespace normalizations, or possible uppercase/lowercase stuff on attribute names, etc.) makes sense to me. Emphasis on "not stored".

The DB team will investigate the impact and complexity of making this change in Whois update. If there are no objections we can plan to include it in the next release. Regards Ed Shryane RIPE NCC