You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If two sites are merged, the original site will have no records in it for site history, so it should do one of three things:
Show a page indicating that the site has no data and was probably merged to another site.
Redirect to the site it was merged to.
Display the information related to the site it was merged to transparently. This may be the preferred manner of handling this situation.
Option 1 has the benefit of being simple/arbitrary. It can be designed such that no matter what site it is we can just show a general "No site data" page.
Option 2 has the benefit of being more user friendly. It has the downside of requiring some sort of "merge-map", i.e. another table in the DB requiring maintenance. (This doesn't happen often so I'm not sure if it's valuable.)
Option 3 could preserve all existing links and the API interactions as well, and treat the old site ID and API parameter as if they were a transparent migration to the new one. This would require much more work on our end but would have the best feel. We could then transparently send all information from the original site to the new one.
Optionally, we could use a modified version of option 3 with the exception that the merged data will only go up to the point it was merged. After that moment data is no longer available. (As if the site was deleted.) This may also prove helpful to push people to use the new site links and whatnot. Then we could have an option to "View new Merged Site" on the page for that site.
The text was updated successfully, but these errors were encountered:
In the case that we go with option 3 the easiest method would be to add a table SiteMerges and then duplicate all the records from the original site but change the PK for them to the new site, then add a record to SiteMerges. This way no major programming has to change and the data will remain accessible to all users for the previous site.
Do note that the /Sites/Default page already omits sites that have no stat records. This means that as soon as a site is merged, if we don't duplicate the data we will automatically remove it from the list.
I like option 2 best. It just sends the user to the updated information without any fuss. The other option I would consider is keeping the sites separate and showing information from the old one up to a certain point, and the new one just contains information from after the merge.
Related:
#8 - Programmers / Software Engineering Merge
#9 - Beer / Alcohol Merge
If two sites are merged, the original site will have no records in it for site history, so it should do one of three things:
Option 1 has the benefit of being simple/arbitrary. It can be designed such that no matter what site it is we can just show a general "No site data" page.
Option 2 has the benefit of being more user friendly. It has the downside of requiring some sort of "merge-map", i.e. another table in the DB requiring maintenance. (This doesn't happen often so I'm not sure if it's valuable.)
Option 3 could preserve all existing links and the API interactions as well, and treat the old site ID and API parameter as if they were a transparent migration to the new one. This would require much more work on our end but would have the best feel. We could then transparently send all information from the original site to the new one.
Optionally, we could use a modified version of option 3 with the exception that the merged data will only go up to the point it was merged. After that moment data is no longer available. (As if the site was deleted.) This may also prove helpful to push people to use the new site links and whatnot. Then we could have an option to "View new Merged Site" on the page for that site.
The text was updated successfully, but these errors were encountered: