Ticket #13021 (assigned Bug)

Opened 4 years ago

Last modified 3 years ago

plone.uuid -- backward compatibility (Plone 4.1.x) and canonical string representation lost in 1.0.2

Reported by: seanupton Owned by: seanupton
Priority: minor Milestone: 4.x
Component: Backend (Python) Version: 4.1
Keywords: Cc:

Description (last modified by seanupton) (diff)

plone.uuid introduced a subtle regression and backward incompatible change between Plone 4.1.3 and 4.1.4, by having the IUUID adapter return a string representation of a UUID inconsistent with previous versions. Previous 4.1.x Plone versions (plone.uuid < 1.0.2) used canonical form with dashes in the UUID string representation; plone.uuid 1.0.2 removed the dashes.

Discussion:

  •  RFC 4122 specifies a canonical grammar for string representation including dashes. It also spells out rules for lexical equivalence.
  • It appears that the canonical form is lost in favor of a (only slightly more compact) hexidecimal representation that is lexically and arithmetically equivalent.
  • Even with lexical equivalence for comparison, both UUIDIndex and FieldIndex are incapable of evaluating this lexical equivalence between (canonical with-dashes and without-dashes) forms.
  • This makes storing and indexing consistent forms for all content necessary for any software to be able to consistently query the catalog from a lexically equivalent uuid.UUID object. However, a migrated 4.1.4 site may have mixed forms stored and indexed, depending on the vintage of
  • Internal code inconsistency: the MutableAttributeUUID adapter is currently inconsistent with the format of the IObjectCreatedEvent handler.

Consequences:

  • Backward-compatibility: create dexterity content objA in 4.1.3, gets a UUID stored with dashes in the string. migrate site to 4.1.4. create dexterity content objB, gets a UUID stored and indexed without dashes in the string. Now, this is not a problem if your add-on does not use UUID objects. But for any add-on that does, you cannot consistently query the catalog for a known string format, since the catalog will contain different indexed values (some with, some without dashes). There is no migration step to solve this problem
  • Interoperability: unless consistent form is used, it is impossible to get a UUID object (say from a ORM like Storm or SQLAlchemy query result) and use that to find content in Plone for a lexically equivalent UUID.
  • Plone's core content relationships are largely unimpacted, but add-on developers relying on UUIDs outside this narrow scope will have challenges for mixed-vintage content or for relating data/content from other storage contexts (in ZODB or RDBMS, or imports from outside systems) to Plone content.
  • Might affect folks moving content to/from external systems other than Plone, where UUID preseveration matters.

Additional thoughts on moving forward:

  • One way or another, we need a migration step, or some consistency. We lack this now. Update: existing UID relationships should just keep working regardless of format for identifier, so writing a migration does not likely solve more problems than it creates.
  • Keeping the no-dashes format introduced in 1.0.2 and migrating canonical form is reasonable, but makes plone.uuid less useful outside of Plone applications. Moreover, it may necessitate not only a migration, but also a normalization of query in UUIDIndex that does not yet exist (would be a good idea to have, unless this burden is to be placed on add-on developers).
  • Reverting back to a with-dashes format is consistent with the RFC 4122 grammar, is easier to detect with regexes, and may or may not require UUIDIndex to normalize.
  • If the commentary on this ticket favors query normalization of UUID representation in UUIDIndex, we should create a distinct ticket for that.
  • I propose a migration step to whatever consistent format is chosen at the very least. I would like to see the canonical representation be used, but that's preference from an interoperability standpoint.

Change History

comment:1 Changed 4 years ago by kleist

  • Status changed from new to confirmed
  • Component changed from Unknown to Backend (Python)

comment:2 Changed 3 years ago by seanupton

 https://github.com/plone/plone.uuid/pull/2 will fix this (includes tests, also includes a new convience marker and adapters for uuid.UUID objects). Can someone review?

comment:3 Changed 3 years ago by seanupton

  • Owner set to seanupton
  • Status changed from confirmed to assigned
  • Description modified (diff)

Updated description per assumptions made in the pull request.

Note: See TracTickets for help on using tickets.