How is the locationhash value in the site items table computed?
I have an item with two entries in that table:
same siteid,
same contentid
same revisionid
same context
same variantid
same location
different locationhash
different contenturl (one is xml assembler, one is /assembler/render)
I wonder if that affects how sys_PublishedSiteItems filters for it. One would think there can only be 1 entry for the same siteid, contentid, varaintid, context, and location (instead of location hash) for the filtering to work correctly. (I understand location hash is used instead of location as part of the table’s primary key.)
The Location Hash is computed with the com.percussion.extensions.general.PSSimpleJavaUdf_toHash class. The source for this class is in the /Rhythmyx/Exits/Java/src directory on the server.
Basically, it takes the delivery location as it comes back from the publisher, converts it to a String and then calls String.hashCode().
Since the locationhash is part of the primary key (and the location is not), your assumption about uniqueness is incorrect.
The String hashcode algorithm is well known, and it should depend only on the contents of the location string. Are you sure that the locations are EXACTLY the same? Any differences (case, a trailing space, etc) will cause the hashcode to be markedly different.
It is mathematically possible (of course) for there to 2 different locations that produce the exact same hash code, but that doesn’t seem to be your issue here.
While working on a customer issue, I encountered this problem and submitted a bug for this.
Here is the bug id and description.
RX-12727 : After each publishing run, RXSITEITEMS table gets updated with published and unpublished items.
The primary columns of this table are SITEID, CONTENTID, CONTEXT, VARIANTID and LOCATIONHASH.
If the same item gets published to same site with other parameters same, the row corresponding to this item gets updated.
The location hash generation has been changed part of a bug fix(Rx-05-10-0052) in 6.0.
When a client upgrades to 6.x and publishes, becuase of the change in location hash instead of updating the exisiting row, publisher inserts a new row.
Even there are two rows for each published item, this will not affect any thing until they move items to archive state.
When they move the items to archive state run the edition with both publish and unpublish content lists, the new row will be updated with pub operation as unpublish and pubstatus as success. But it leaves the first entry(5.7 entry) as is, which will have puboperation as publish with status as success.
That is also fine.
In the next run, the unpublish content list picks up this item.
As it looks at the items that are successfully published earlier and in archived state now.
But the item in question has already been unpublished from the site in the first run, the second run causes a failure.
Even though it is not a real error, clients get confused as these errors keep coming after each unpublish run.
Here is the workaround suggested in the bug: Stop working on the content.
Run unpublish edition.
Take a backup of RXSITEITEMS table.
Clear the data from RXSITEITEMS table.
Run a full publish.
An upgrade plug-in has been written to resolve this issue and is part of the 6.6.