[UPDATE – Mar 26] As of the 1.19.1 server update, the larger of the two parcels selected keeps the parcel ID.
Four days ago, Resident Phil Deakins reported a drop in the search ranking for his low prim furniture business. Phil, my apologies for using you as our example! The drop in search ranking followed Phil’s purchase of additional land, which he joined to existing land. You can see Phil’s original, more detailed description at: http://forums.secondlife.com/showthread.php?t=244502.
I apologize for the lengthy and somewhat technical nature of this post, but I want to be clear about what happened and what we are doing to fix it. The search team has also created updated documentation on parcel joins for the Second Life wiki and the Knowledge Base.
New Search and Land Parcel IDs
The new search pays attention to land parcel ID, unlike most human beings do. This means that Top Picks or a Landmark, for example, may point to a new SL business in its correct, current location, while behind the scenes search is looking at land parcel ID instead – and the two don’t necessarily match following a parcel join.
You cannot see the underlying land parcel ID numbers in the Second Life user interface. In search, they are the end of the URLs for the pages, like http://world.secondlife.com/place/44671d64-69a6-a522-7f33-c23fcc62e1c4 (Governor Linden’s home).
Unfortunately, magical though the Google boxen may be, search cannot do a detection query that asks “Have land parcel IDs changed?”and update the land parcel IDs if they have changed.
How Parcel Joins Work
Phil’s report helped us identify a major design flaw in the way parcel joins are handled in our database (not in search, but in the database). When you join two parcels you will get the parcel ID of one of the two, but you cannot predict which. Thus, you might get the ID of your popular, highly ranked parcel, or you might not.
We drilled into what determines which parcel gets which ID and why. Initially, we thought the size of each parcel mattered (i.e., that the larger of the two kept the old ID) but found that the age of the parcel mattered (i.e., when Linden Lab created the parcel, not when a Resident purchased it). Our parcel manager code essentially took a set of parcels and sorted them numerically by internal integer ID. This internal integer ID describes the order in which the parcel was created, and the older parcel wins.
Obviously, the time when Linden Lab created a parcel should not be highly relevant to join operations. The parcel creation date is not helpful information that Residents can see and use when they want to join land parcels. So, we started changing this yesterday.
What We Are Doing to Fix This
This fix requires a change to the simulator code. We are changing parcel joins to behave in the way we expected them to, which is: When joining two parcels, the largest parcel keeps the parcel ID. This fix will be deployed to the main grid in 1-2 weeks, when the next round of server-side code goes out.
We regret that we cannot make individual database fixes for Residents who have encountered this issue.
What Residents Can Do
A few additional changes will help improve Phil’s search ranking and those of other Residents who may have experienced the same problem.
Right now, there are twice as many Top Picks that link to Phil’s former store location. While some of this is due to the land parcel ID change, Phil can rename the old store to have the same prefix as the new one, which will help Residents find the new location. For example, if your old store was called “Foo Sculpties,” it would be better to name it “Foo Sculpties (closed)” than just “Closed” or “Closed – Foo Sculpties.”
Phil can also ask his customers to re-add his store’s location (complete with the new land parcel ID number) to their Top Picks.
Phil also mentioned that Show in Search was not checked. Show In Search defaults to off, so please make sure you select it when joining land parcels. We still feel that defaulting Show in Search to off is safer for Residents, some of whom strongly wish to remain out of search results, but if you want to appear in search make sure to explicitly select that option.
Thank you, Phil Deakins, for a detailed report that helped us identify and fix the root cause of this problem.