Request for a DB-driven report/list/log of all system/page name-changes

[QDP2012]

Good morning RRDBAs,

Request

• Is there now, or could you please make available, a permanent DB-generated report (like an ongoing log), sorted in most-recent-to-oldest order, that lists all system/page name-changes that have been made anywhere in the DB?
  
  (This might need to include names of newly created pages, to cover the situation when multiple DB pages are consolidated into one new page.)

Reason

• When a system (or page) gets renamed in the DB, the related Wiki page (the one with the same name as the DB page's old name) can easily become "disconnected" from the DB and in some cases basically "lost" until a Wiki-Admin or Wiki-editor stumbles across the Wiki-page. and then only if the page-name difference is discovered.
  
  Since many of the DB-related Wiki-pages do not yet have "Return to DB page" links that clearly match the Wiki page to a specific existing (or former) DB page, it is not always obvious that a DB-page's name has changed, without navigating first to the DB, navigating to the target county, and verifying manually that the system/page in-question still exists or has been renamed.

Examples

• An example of how easily a Wiki-page (or pages) can become disconnected from the DB is the recent name-change applied to the DB page: FleetConnect (158). Until very recently, it was named "TURBO CONNECT Plus (158)‎".
  
  When this system was renamed, it became disconnected from the related "TURBO CONNECT Plus (158)‎" page in the Wiki.
  
  Thankfully, soon after the DB page-name was changed, someone noticed the "disconnection" and began the process of updating the Wiki so that the corresponding Wiki page would be "reconnected" to the DB. (The person who started updating the Wiki happened to be a DBA, but wasn't the one who had changed the DB-page's name. Someone else helped finish updating the 34 other Wiki-pages that also had to reflect the system-name change.)
  
  
• Other examples:
  
  In the current review and update of the Wiki's aviation related pages, and in previous reviews of TRS pages, quite a few Wiki-pages have been discovered that were "disconnected" from the DB as a result of a system/page being renamed in the DB, like when multiple airport-pages were consolidated into one.
  
  Again, please notice that these "disconnections" were "stumbled upon" by chance, not by intent.

My opinion

• I very easily could be wrong, but from what I've read in older threads in the Forums, it seems that many, if not most, of the RRDBAs are very well skilled and experienced in maintaining the DB, but might not have the same skill, experience, and comfort-level, with Wiki-editing, not to mention the additional time it requires.
  
  And, even though their efforts to help maintain the Wiki and avoid problems like this are greatly appreciated, in my opinion,
  • RRDBAs should not need Wiki-proficiency in order to be a DBA, and
  • the Wiki's accuracy should not be.dependent on a DBA remembering to update the Wiki when a DB-page's name changes.
  
  
• In my opinion, the Wiki-Admin(s) and Wiki-editors should be able to view a DB-driven report that lists the system/page name-changes that are made anywhere in the DB, so that they can quickly and correctly adjust the corresponding Wiki-pages' name(s) accordingly.

Conclusion

• Both the DB and the Wiki have grown significantly in recent years, and can be expected to grow significantly in the near future, especially with the release of ProVoice, DMR, and NXDN -capable scanners. Statistically speaking, the problem of Wiki pages becoming "disconnected" from their corresponding DB pages will only increase over time, as the DB and Wiki grow overall, and as their structure is updated accordingly.
  
  
  
• The question is how to reliably and easily identify such "disconnection" situations.

Benefit

• A DB-driven report or log of system/page name-changes, sorted from most-recent-to-oldest, would
  (1) help lift the individual Wiki-editing burden from any particular DBA who needs to rename a DB page, and
  (2) allow anyone (whether another DBA, or any Wiki-editor) to intentionally investigate and verify, instead of stumbling upon, a "disconnection", and
  (3) allow anyone to make the necessary adjustments in the Wiki, and make them sooner rather than later.

Thank you for your consideration. All ideas and suggestions are welcome.


Respectfully,

 

[kruser]

I could see the benefit of having this ability at times.
I would definitely use it if it was available as sometimes I may go a few weeks without checking the DB and I miss the color change that lets you know something has changed.
Then if a system has a ton of changes, the Downloads & Reports tab will only display so much information before it starts writing over new info.

Some DB Admins also forget to check the box that makes a change visible so it can be hard to tell what actually changed sometimes.
If we had a running change DB like you are suggesting, any and all changes should be logged in it even if a DB Admin forgets to mark something as new.
I don't know how hard this would be to implement but maybe Lindsay will chime in as I think he does most of the coding of his site here.

 

[QDP2012]

Thanks for the reply.

If we had a running change DB like you are suggesting, any and all changes should be logged in it even if a DB Admin forgets to mark something as new.

Even though a comprehensive list/log of all DB changes as you describe above could be useful in other situations, in this case I would want only both "system/page name-changes" and "new systems/pages" listed, but not any other DB-changes, so that the (likely) "disconnections" can be identified quickly, without wading through all other DB updates.

Just one opinion,

 

[darunimal]

IN OT: I would also like the DB Map to have 2 Additional Colors for Month and Year, because not everyone checks daily or weekly to see DB Changes and it isn't valid to think 75% of our community checks that often. Red and Blue would be my choices.

I do like your idea of a "Recent Changes Log" for the DB like the Wiki uses, that would be nice and with the Wiki we already have a valid working template to go off of.

 

[ka3jjz]

While I can see the value in such a report, I'm willing to bet that it would be huge - the number of changes applied in, say, a month might be overwhelming. I'm unsure of how someone (maybe even a team) would keep up with this.

Perhaps the report could somehow be limited to just new and renamed entries? I would think (and I am not a database admin, nor do I play one on TV...:.>>) the report would be considerably smaller and therefore easier to handle? Mike

 

[blantonl]

Trunked System name changes don't happen too often, but you raising awareness to an issue that needs to be addressed. I just today changed the name of a large Florida NXDN system that had a pretty extensive Wiki collaborate page. Because of this post I consciously went in and moved the article to a new home.

I'll look at a programatic process to make this issue of the Wiki name change happen automatically, the ... but in the meantime, it might just make sense for me to implement a process where we alert the admin to check if a Wiki collaboration page exists for the system, and to instruct them to make sure that the Wiki content is moved to the new page. Honestly, if I didn't see this earlier, I would have abandoned a lot of crucial data.

Reporting, while great, is a passive medium for making things happen - it requires us running reports vs people getting notified or things just happening. I hate to get into report writing mode to address administration issues.

Let me have a look at a way to automatically change the Wiki article name with a TRS name change.

 

[QDP2012]

Please notice some needed clarifications, sir

Thank you Mr. Blanton, for your attention to this matter. Respectfully sir, I need to clarify some points. Please read below.

(EDIT: Please excuse any repetitive statements. I tried to limit repetition while yet being detailed, but clearly did not eliminate it.)

---

Trunked System name changes don't happen too often... Let me have a look at a way to automatically change the Wiki article name with a TRS name change.

My OP might not have been clear enough or used the correct terms in its description, and you might already be considering this, but for caution and clarity...


Please notice that this "DB-Wiki-Disconnection" problem happens with every single name change of every page in the DB (not just TRS system-name changes) when said change causes the DB-page's "Wiki button" link to change also.


Some examples of existing DB-changes that have already "disconnected" the DB from Wiki-pages (others might yet be undiscovered):

• When a TRS system-name changes (detailed examples are earlier in this thread).
  
  
• When a county-name changes
  (like when New York's counties were renamed -- [Bronx County, Kings County, New York County, Queens County, and Richmond County] became [Bronx, Brooklyn, Manhattan, Queens, and Staten Island] and were made part of NYC.)
  
  This happens infrequently, but has happened in more places than NYC, including other U.S. counties, and counties/districts in other countries..
  
  
• When any DB page is renamed due to syntactic problems
  (removal of pound, ampersand, etc.) (Discussion: Syntactic problems with the pound/number symbol)
  
  Several have been handled already. Several other DB names need to be changed, but those items have not yet been submitted to the DB Team yet.
  
  
• When a county's one airport page has the FAA LID added in parentheses to the page-name's end. Also, the FAA LID of several airports has changed in recent years as airports grew in size and importance.
  
  
• When a county's one airport was listed with a separate page under the "Agencies" tab, but has since been restructured as a sub-section on the county's main DB page.
  
  
• When a county's multiple airports are no longer given separate DB pages under the "Agencies" tab, but are merged into one "Airports..." page, under the "Agencies" tab.
  
  
• When a DBA restructures or renames any of the conventional pages listed under a county's "Agencies" tab/list.
  
  
• When a county's "Businesses, Media, Railroads, and Attractions" page is renamed or separated into multiple pages
  
  
• When the military entities are renamed due to BRAC decisions, etc.
  
  These have involved "simple name-changes".
  These also have involved the merger of several entities into a "Joint Base".
  
  "Joint Base" issues usually require several Wiki pages to be evaluated, possibly renamed, and/or merged. Several "disconnections" of this type have been discovered in recent years and been "reconnected", including some that were found recently.
  
  
• Edit: When "Federal" or "Railroad" or other "State-level" listings are renamed
  • e.g. "Federal (ST)" becomes "State Federal (ST)" or vice-versa
  • e.g. "Railroads (ST) becomes "State Railroads (ST)" or vice-versa
  • etc.
  
  
• Edit2: When a "Multi-State" DB-page has another state's abbreviation added to its page-name.
  (e.g. multi-state TRS, multi-state business, multi-state national park, etc.)
  (A DBA just updated several Wiki-pages in this manner after a name-change to one "TRBOWEST" page in the DB).

These are just the ones that quickly come to mind that we have already encountered in trying to maintain the WIki. There might well be other scenarios as well that are not yet discovered, because, as far as I know, the Wiki has not been fully processed for this purpose, yet.


---

I just today changed the name of a large Florida NXDN system that had a pretty extensive Wiki collaborate page. Because of this post I consciously went in and moved the article to a new home.

Thank you sir for your efforts in this regard, and even though you certainly know this....

Please let me mention for the benefit of others who might read this post, that...

• even though the "natural" thing many people want to do is to attempt to create the "new"-named Wiki page, and then copy-paste data to it from the "old" page,
  
  
• the ideal way (per Wiki help documentation) is to find the "old" Wiki page and to use the "MOVE" button, because it preserves and transfers the "old" page's Wiki-history log, which can be useful at a later date for several reasons.

---

I'll look at a programatic process to make this issue of the Wiki name change happen automatically...

I understand and agree with you about programmatic being better than manual procedures.
As mentioned above, it would be ideal if a programmatic solution could invoke the "MOVE" feature, instead of creating a new page and losing history-logs.


---

... but in the meantime, it might just make sense for me to implement a process where we alert the admin to check if a Wiki collaboration page exists for the system, and to instruct them to make sure that the Wiki content is moved to the new page.

As I am sure you have easily noticed, the DBA must first check for the existence of a Wiki-page BEFORE renaming the DB page.
Else, it can be more difficult to find the formerly-connected Wiki page, especially if the name change is significant.


---

Honestly, if I didn't see this earlier, I would have abandoned a lot of crucial data.

W9BU, ka3jjz, ibagli, and several others, including DBAs, have been "reconnecting" the "disconnected" pages over the last several years, and trying to keep data from being "lost" in the Wiki. The thing that brought this to the forefront seems to be the large influx of data into the Wiki from the recent DMR discoveries, and the DB updates as more details are learned about those systems.

But, the problem is DB-wide and Wiki-wide since it relates to every name-change in the DB, not just TRS-systems. My best guess is that most of the "disconnected" pages have been handled, though there are probably a few still to handle.

My concern is how the problem might grow as more conventional and trunked data is added to the DB and supporting information added to the Wiki.


---

Reporting, while great, is a passive medium for making things happen - it requires us running reports vs people getting notified or things just happening. I hate to get into report writing mode to address administration issues.

As someone with years of DB and programming experience, I understand and agree wholeheartedly.

But, please reconsider the report option, because "MOVE"ing a Wiki-page is NOT the only Wiki-edits demanded by a DB page name-change.

Other Options:

Some other ideas (which would involve more work to implement) could be:

• Another option might be if you could make the "alert feature" you described above, available to everyone, not just that page's DBA, so that any of us who help maintain the Wiki, could "sign-up" for that "page-name change" alert The difficulty with this is that it could/would overflow the PM box for those of us that use PMs regularly anyway.
  
  
• Maybe a report and the alerts could both be available, so that an alert would fire once notifying the recipient via PM that a particular DB-page's name has changed, and that the recipient will need to view the report to see a list of all the names that have changed.

Reasons to reconsider the Report option:

Even though my OP mentions that the suggested report would

• (1) lift the Wiki-editing burden from the individual DBA, and
• (2) make it easier for Wiki-Admins and Wiki-editors to have access to a list of DB pages to evaluate and verify that they are still appropriately connected to any related Wiki pages,

those are not the only considerations from a Wiki-Admin or Wiki-editors perspective.

As mentioned earlier, sir, the simple process of "MOVE"ing a Wiki-page is not the only thing that needs to be done following a DB-page's name-change.

• Example: For each TRS name change in the DB:
  • the TRS's primary Wiki page needs its name changed
  • the TRS's primary Wiki page needs its InfoBox parameter(s) updated accordingly
  • the TRS's primary Wiki page needs its narrative paragraphs updated
  • the TRS's primary Wiki page needs its section-headers updated (in some pages, not all)
    
    
  • the TRS's secondary Wiki pages (example list below) need their page-names updated also
    • the RID/UID pages,
    • the Unknown Talkgroups pages,
    • the "DMR Bandplan" pages,
    • the "Miscellaneous Information" pages
    • and any other "children" Wiki pages for that TRS
  • the TRS's secondary Wiki pages need their InfoBox parameter(s) updated accordingly
  • the TRS's secondary Wiki pages need narrative paragraphs updated
  • the TRS's secondary Wiki pages need section-headers updated (in some pages, not all)
  • etc.
  
  
  
• Example: For each Aviation / Airport / Airbase / etc. name change in the DB:
  
  (this includes changes of not just DB-page names, but also changes of section-headers on a multi-airport "Aviation..." page in the DB.)
  
  • the Airport / Airbase's listing needs to be updated
  • this might involve "MOVE"ing a Wiki-page to update a page-name
  • this WILL involve updating the "InfoBox" parameters for the Aviation entity.
  • this often involves updating narrative descriptions
  • this often involves updating external URLs and their descriptions to reflect the name-change
  
  
  
• Example: For EVERY name-change (including TRS name changes):
  • the pages listed in the "What Links Here" list need to have their links updated accordingly.
    If, on these pages, these links are in a list, then the list probably needs to be re-sorted.
    
    
  • the related pages need to have their "Return to" navigation links updated accordingly.
    ("Return to" links should (but don't yet) exist in each Wiki page, to prevent dead-end pages.)
    (The syntax for "Return to" links are not (yet) consistent, though template-calls are being used to replace non-template links where appropriate.)
    
    
  • when all other related-pages are updated such that the "redirect-page" (created by the "MOVE") is no longer needed, then the "redirect-page" itself needs to be blanked and deleted.
  
  
  Unfortunately, I have helped grow the list of pages that W9BU will need to delete, including a variety of pages that contained redirects used when "reconnecting" pages to the DB after a DB-page's name-change.

Please note:

• In summary, sir, it might not be practical to attempt, nor possible, to automate all of the Wiki-changes that need to happen (or investigated and ruled-out) every time any DB page experiences a name-change.
  
  
• Because manual changes will need to be made in the Wiki (even if automation helps with some of the initial steps), a DB-generated "name-change" report (which lists every name-change in the DB, not just TRS name-changes), which anyone can view, will still have significant value for those who try to maintain the Wiki.
  
  
• Also, as a suggestion, if, for each name-change action listed in the report, that report could display click-able links...
  • to each effected DB-page
  • and the old "Wiki-button" link formerly found on the old DB-page (this option might not be possible)
  
  ...then that would allow a Wiki-Admin or Wiki-editor to navigate much more quickly as they validate or update page-names in the Wiki.
  
  This above is just a quick thought. W9BU, ka3jjz, ibagli, and others with years of Wiki experience would be better resources for suggestions about what to consider when deciding what to include in the report.

---

Let me have a look at a way to automatically change the Wiki article name with a TRS name change.

Thank you again, sir, for your attention and efforts. Again, the "DB-Wiki-Disconnection" problem is not limited to TRS pages, but applies to every name change in the DB.


Respectfully,

 

[Voyager]

I'll look at a programatic process to make this issue of the Wiki name change happen automatically,

Maybe the pages should be assigned ID numbers when they are created - much like systems, states, and counties. Then the links can refer to that permanent ID number link rather than a name which might change.

This is not unlike the Permalink feature on the forum posts.

 

[QDP2012]

Maybe the pages should be assigned ID numbers when they are created - much like systems, states, and counties. Then the links can refer to that permanent ID number link rather than a name which might change.

This is not unlike the Permalink feature on the forum posts.

I don't know if there are completely unique numbers for each page, but the URL for each page involves a "page-type indicator" and a "page-number".

Example:

http://www.radioreference.com/apps/db/?[b][u]ct[/u][/b]id=[b][u]383[/u][/b]

The page-type is "ct" (abbreviation for "county")
The page-number is "383".

Edit: I think the page-number values can be reused, but the combination of the page-type and page-number creates a unique result, though.

Often, these match those used in BCFY pages also.

Hope this helps,

 

[Voyager]

I don't think I've ever seen a state, County, or System page ID change. I call it an ID and you call it a Page Number, but it's the same thing either way that should be applicable to any pages created. The key is that it is a permanent reference (pun not originally intended, but so be it).

 

[QDP2012]

I don't think I've ever seen a state, County, or System page ID change. I call it an ID and you call it a Page Number, but it's the same thing either way that should be applicable to any pages created. The key is that it is a permanent reference (pun not originally intended, but so be it).

There is a discussion in another thread about railroads in NJ. In the DB, there is an old DB page, and a new DB page existing at the same time for the NJ RRs. I am guessing that when the new page is done, the old page will be deprecated and/or deleted. That might be a situation where it will seem that the page ID number changes at the same time the page-name changes. I'm not sure if that is what you are describing.


Also, from what I can tell, the page ID number is unique for a certain page-type, but not across the entire DB. During the ongoing aviation-page project in the Wiki, I bumped into a few situations where the page ID number of an aviation page (which is treated as an "agency" and has a URL ending with .../?aid=####) was the same page ID number assigned to a county-page (which has a URL ending with .../?ctid=####).


The combination of page-type and page ID number is unique, though.

Hope this helps,

 

[AK9R]

Maybe the pages should be assigned ID numbers when they are created - much like systems, states, and counties. Then the links can refer to that permanent ID number link rather than a name which might change.

This is not unlike the Permalink feature on the forum posts.

Wiki articles are referred to by names and those names, by default, consist of the title of the article. That's the way most wiki software works. In order to use an ID number linked to an article, the Wiki would have to contain many, many REDIRECTs, a built-in wiki feature that allows automatic redirection from one article reference to another. Over time, maintaining those REDIRECT articles might prove problematic and easily broken.

I think the best we can hope for is a programmatic solution, triggered when a DB page is renamed, that looks at the previous Wiki article name and MOVEs it to a new Wiki article name. However, as QDP points out, we'll still need a report of these moves because there may be links to article embedded in other articles that will be affected by the move requiring hand editing.

 

[QDP2012]

Over time, maintaining those REDIRECT articles might prove problematic and easily broken.

I agree, and would make this a stronger statement based on the 2013-2014 efforts at cleaning up the 1500+ REDIRECTs that existed at that time. As I recall, between 500 - 1000 REDIRECTs had to be manually inspected (check the REDIRECT's target Wiki page, check the matching DB page for page-name validation, etc.) before each unnecessary REDIRECT could be added to the "ready-for-deletion" list. Other REDIRECTs were preserved "temporarily" but were flagged with obvious notes about which DB-page was related. Some of these "temporarily preserved" REDIRECTs have now been deleted, but some still exist.

In my opinion, the Wiki's REDIRECT feature has a specific and useful purpose, but there should be as few REDIRECTs as possible. Maintaining those REDIRECTs is worse than maintaining normal Wiki-pages, with respect to keeping the page-names straight.

Just one opinion,

 

[QDP2012]

New element to the problem - a "Partial Disconnection"

There is a discussion in another thread about railroads in NJ. In the DB, there is an old DB page, and a new DB page existing at the same time for the NJ RRs. I am guessing that when the new page is done, the old page will be deprecated and/or deleted. That might be a situation where it will seem that the page ID number changes at the same time the page-name changes. I'm not sure if that is what you are describing.


Also, from what I can tell, the page ID number is unique for a certain page-type, but not across the entire DB. During the ongoing aviation-page project in the Wiki, I bumped into a few situations where the page ID number of an aviation page (which is treated as an "agency" and has a URL ending with .../?aid=####) was the same page ID number assigned to a county-page (which has a URL ending with .../?ctid=####).


The combination of page-type and page ID number is unique, though.

Hope this helps,

Thinking about the NJ RR situation, mentioned above, brings to-mind another problem or element regarding "DB-Wiki-Disconnection", that is a "Partial Disconnection".

Description of "Partial Disconnection"

(This has happened before in the DB, and been "reconnected" in the Wiki accordingly.)

The DB can become partially disconnected from the Wiki when a DBA creates a new DB page (URL example: .../?aid=9999) and assigns the exact same page-name to it that has been assigned to the old DB page: (URL example: .../?aid=8888).

In this situation, the page-name would not have changed, which means the new DB-page's "Wiki button"'s URL will be the same as the old DB-Page's "Wiki button"'s URL, which means the "Wiki button" will still navigate to the correct Wiki-page, and will not require a "MOVE" action in the Wiki.

The problem is that on the related Wiki-page, the "Return to" links that let a Wiki-visitor navigate from the Wiki directly to the related DB page, will now be BROKEN, because the DB-Page's URL has changed.

The "Return to" links on the related primary Wiki page (and on any children Wiki pages) would need to be updated manually so that they no longer point to the old DB-Page's URL (URL example: .../?aid=8888), but instead point to the new DB-Page's URL (URL example: .../?aid=9999), even though all of the pages (old DB-Page, new DB-Page, and primary Wiki Page) each have the same unchanged name.
​

How to Identify such "Partial Disconnections"

This does not sound like an elegant solution at all, but at quick glance, the only thing that comes to-mind, is to have the "DB-page name-change" report (requested in the earlier posts), also include "URL-change" actions but only for those cases where the name stayed the same and the URL changed.

Edit:
Please note that even if the "DB-page name-change" report were to also list all new DB-pages (which I think it should, as was suggested earlier in the thread), that still would not sufficiently highlight the "same name but new URL" actions, because a person checking the new DB-page might use the new DB-page's "Wiki button" to navigate successfully to the existing Wiki-page, and not discover that the Wiki-page's "Return to" links point to the old page's URL, especially if the old DB-Page is still available (like the old NJ RR page is at the moment, or like those TRSs which have been "deprecated" but which have not changed names as the old DB-page was "replaced" by the new DB-page). Several TRS pages have been "partially disconnected" in this manner, and later "reconnected" when discovered.
​

Thanks for your consideration.

Respectfully,

 

[QDP2012]

Good evening,

Just checking to see how far along the development of a report (or other solution) might be?

The renaming of any page in the DB still disconnects its related primary Wiki page. Fortunately, more people are trying to catch these situations and to at least move the primary Wiki article accordingly. This helps a lot, but still leaves some vulnerabilities.

Though this is not the first time, one entity was recently found which had been renamed more than once in the DB, without all of its related secondary Wiki pages being renamed, and linked pages being updated, accordingly.

Cleaning-up the Wiki after an entity has been renamed once can be tedious; doing it after multiple-renaming can be very tedious and nearly impossible if not caught while any related "redirects" are still active. If a "redirect" gets dropped prematurely, its dependent pages will be orphaned with little trace of the proper relation to other pages.

The aforementioned report will be very valuable, and used as soon as it becomes available.

Thank you again for your consideration.

Very Respectfully,

 

[QDP2012]

I think the best we can hope for is a programmatic solution, triggered when a DB page is renamed, that looks at the previous Wiki article name and MOVEs it to a new Wiki article name. However...we'll still need a report of these moves because there may be links to article embedded in other articles that will be affected by the move requiring hand editing.

Good morning Mr. Blanton,

Having thought about this whole situation some more, I think W9BU's recommendation is dead-center on-target. We need the "MOVE" action automated whenever a page/system in the DB is renamed, which has an existing Wiki page that would become "disconnected".

But, even if a programmatic solution is/could be developed which would accordingly "MOVE" Wiki pages to prevent "direct disconnection", the Wiki's own Wiki-engine-driven "MOVE Log" would NOT be sufficient for tracking DB-changes that require follow-up attention in the Wiki, because there are pages in the Wiki which link directly to a specific DB-page, but do not necessarily link to that DB page's matching Wiki page (especially if that Wiki page has not been created yet).

Because of reasons mentioned in earlier posts in this thread, and especially because of ongoing current efforts to make the Wiki more database-like, (and the planned future changes as part of those efforts, including adjustments to the Wiki's structure, templates, and naming-conventions, etc.), I think:

• (1) it is not possible, at this time, to programmatically automate anything other than the first-step "MOVE" of an existing "primary" Wiki page which shares the same name as the corresponding DB-page,
  
  
• (2) the programmatic-logic that executes the "MOVE" of an existing "primary" Wiki page, should NOT attempt to delete the automatically created "REDIRECT" page which the "MOVE" action creates. (This REDIRECT will need to be preserved until all other related corrections in the Wiki have been made manually; then the REDIRECT can be blanked/deleted manually)
  
  
• (3) the DB-driven "name-change/new-page/URL-change" report requested above is still NEEDED, because, the Wiki's own Wiki-engine-driven "MOVE" log is NOT sufficient for tracking the DB-changes, because there are Wiki pages which link directly to multiple DB-pages, but do not necessarily link to those same DB-pages' matching Wiki pages (particularly when those Wiki pages have not been created yet).
  
  
• (4) there is a surprising amount of Wiki-content that textually mentions/discusses/names entities in the RRDB, but which are not actually (yet) linked to said DB pages. Whenever a DB-page is renamed, that non-linked textual description needs to be updated as well. This means that Wiki-editors need a list of all such changes in the DB, so that the Wiki's content (not just the Wiki-page names) can be properly updated.

In conclusion, please reconsider creating the DB-driven report requested above.

• Making the report now would relieve pressure for an automated solution, which could be incrementally developed, tested, validated, and deployed, later as developers' time allows. No doubt, DB-developers are very busy with many important DB changes related to new scanner technologies.
  
  
• I believe that no programmatic solution to the Wiki problems mentioned in this thread will be able to fully automate every change that needs to happen in the Wiki following a name-change in the DB.
  
  
• Because manual Wiki-editing will be required for the foreseeable future, the requested report is vital not only to keep Wiki pages properly connected to the DB, but also because it likely will help avoid Wiki-editor-fatigue in trying to find such disconnections so they can be fixed.

Thank you again for your time, consideration, and for helping develop an appropriate solution.


Respectfully,

 

[QDP2012]

30+ Wiki pages disconnected by one name-change in the DB

Good evening,

Another good example of how the requested report would help avoid the problems described above, is with the partial-disconnection that happened when the "FL Railroads" DB page was renamed to "Florida Railroads" in the DB.

Prior to the DB-page being renamed, there was no direct corresponding primary Wiki page that paired with that DB page...

...BUT, there were more than Thirty (30) Wiki pages that needed to be updated because each had a "Return to" link pointed at the "FL Railroads" DB page, which had to be updated to point to the "Florida Railroads" DB page.

The requested report would have listed the name-change that happened in the DB, which would have given the Wiki-editors a "heads-up" on the possible partial- or complete- disconnection in the Wiki.

On the Wiki-side, this situation could only be identified manually, not in an automated manner; which reinforces the need for the requested DB-driven report regardless of any automated "MOVE" feature that might be developed in conjunction with the report.

I hope this additional example helps clarify the strong and increasing need for the requested report.

Thank you again for your consideration.

Respectfully,

 

[blantonl]

This isn't an easy fix, but it is on my radar and I am aware.

 

[QDP2012]

This isn't an easy fix, but it is on my radar and I am aware.

Thank you sir for your time and attention and reply.

 

[QDP2012]

Disconnection between DB and Wiki's Red-Links

Good morning sir,

Another DB-Wiki disconnection scenario...

History

As I am sure you know, in the Wiki there are almost 15,000 red-links (links to future Wiki pages). The Wiki-editors who put the red-links in-place made the Wiki more useful and convenient, and more easily edited by new contributors, because the red-links provide new contributors with a clearly marked place to put their information.

A large percentage of these red-links exist because in past years, multiple Wiki-editors took the time to navigate the DB and determine each "Wiki-button" link that is associated with individual DB-pages of-interest, and then to put these links into the Wiki, so that whenever a Wiki-contributor would be able to create the desired Wiki-page, the DB-Wiki connections would already exist and would become live at that time, enabling Wiki-visitors to navigate between Wiki-pages and between the Wiki and DB appropriately.​

General problem

The years of work to mature the Wiki as mentioned above now expose a less-obvious example of DB-Wiki disconnection, which cannot be verified by checking for an existing Wiki-page prior to renaming the DB-page, and that is the disconnection that happens between the DB and any existing red-link in the Wiki, which points to a not-yet-created Wiki page that formerly corresponded directly to a DB-page, but which is now disconnected because the related DB page was renamed since the red-link was created.


This can relate to any DB-page, but for convenience, the example below will describe a disconnected TRS that was discovered today.​

Example of How it Happens

(Example used is from a TRS-disconnection discovered today, but the problem is not at all limited to TRS pages.)

In previous years, previous Wiki contributors have created a "Trunked Radio Systems (ST)" page for each state (and several other countries), which lists the Wiki links for all TRSs that are listed in the DB for that specific state, at the time the Wiki-list was created. Some of the links point to existing Wiki pages, but many are red-links that point to Wiki-pages that have not been created, yet.

With the lists of links on the 50+ "Trunked Radio Systems (ST)" pages, a Wiki contributor can click on the desired red-link and create the desired TRS Wiki page, without having to first navigate to the related DB-page in the DB in search of that DB page's "Wiki" button.

This creates a situation where a Wiki-contributor can navigate to the related "Trunked Radio Systems (ST)" Wiki page, and click on the red-link for that TRS (which has not been updated after the TRS was renamed), and thus create a new page for that system which is incorrectly named and is disconnected from the DB at the moment it is created.


Example: WE Energies, which was previously listed on Trunked Radio Systems (WI) as "Wisconsin Electric Power Company (We Energies".​

Please Note:

As you know sir, this is not limited to only TRSs. This relates to ANY DB page, because it happens every time a Wiki-page contains a red-link that points to a yet-to-be-created Wiki page, which matched the DB-page's name prior to the DB-page being renamed, but which became disconnected because the DB-page was renamed. This is true whether the page is for an airport, a business, a park, etc. -- for any entity, not just a TRS.​

In Summary

In summary, whenever any page is renamed in the DB (not just a TRS, like the one used in the convenient example above), there very likely will be a one-direction or two-direction DB-Wiki disconnection, which might not be obvious, and which will need to be verified/corrected manually.

The variety of situations which can lead to DB-Wiki disconnections make it difficult (and probably impractical) to find a programmatic solution, which would automatically update all of the related entities in the Wiki whenever a DB-page is renamed..​

Thank You

Thank you for keeping the requested reports on your "To Do" list. Even though I agree that the use of reports is clearly not the ideal way to solve operational problems when a programmatic solution is viable; in this case, it seems to be the best option.

I believe the requested report(s) will be used frequently, regularly, and will directly and immediately help correct the as-yet-undiscovered DB-Wiki disconnections, and allow a much more rapid identification and correction of future DB-Wiki disconnections. As W9BU mentioned earlier, a practical programmatic solution might help solve the easy low-hanging-fruit (like renaming an existing primary Wiki page), but the requested report(s) still will be needed because there will always be things that need to be checked and corrected manually.​

Thank you again for your time and consideration,