Announcement

Collapse
No announcement yet.

Thread ID's changed, links to your site no longer work?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Yeah, I understand the reason why they can't be transitioned... I just had issue with the statement that it's "bad practice" to retain unique IDs when possible.
    Sphinx Search for vBulletin 4: https://marketplace.digitalpoint.com...tin-4.870/item
    Someone send me a message on Twitter when this site is usable again. https://twitter.com/digitalpoint

    Comment


    • #17
      Originally posted by Zachery View Post
      Okay,

      So a quick run down, is that in order to transition the system into the new db schema the new key ids don't really match their old counter parts.
      We had things like postid, threadid, blogid, groupid, socialgroupmesageid, pmid, forumid, etc. these can't be carried over 1:1 into the new schema because of the schema.
      We keep these old ids mapped properly. So if someone comes in via showthread.php?t=X or p=Y or forumdispay.php?f=Z they get redirected to the proper item in the new system.


      Am I making more sense now?
      Yes you are. It is a fallout of the single node table.

      I think at the very least, threadids could have been preserved, and starting the numbering of other content types from where thread ids finish. This way about 80% of the redirect overhead could have been saved.

      Overall I am not a huge fan of the schema with the single node table. I understand that a single table structure for different content types is a good thing, but overall there are the performance risks of querying for say a visitor message on a say, 20 million rows node table.
      Owner: Oracle Forums - General Discussion Forums.

      Comment


      • #18
        Zach, OR....there was another option for your developers. Have a combined primary key in the NODE table (I'm assuming it's called node). RecordId, ContentTypeId. This way you can easily map old Ids in the new system with this setup without storing OLD ids altogether. The only difference with this setup is that you no longer have auto-generated keys (you have to get Max(recordid) from node where contetypeid = X). But since new requirements for vB5 is MySql 5, they could use stored procedures, which cache sql statements a lot better than running them dynamically.

        I really don't want to bash vBs developers but there is a HUGE difference between doing it right and doing it "anyway, as long as the functionality does what I want".
        Speed up your member list page by at least 5x (4.x.x)

        http://nicknameregister.com/files/20...0/ShyGuy82.jpg

        Comment


        • #19
          Originally posted by Dirt Bike Addict View Post
          So does this mean that any links to my site that are posted on another site, could be directed to the wrong thread as the thread ID number changed?
          Actually old links to your site should continue working and automatically link to the new URLs for items.
          Translations provided by Google.

          Wayne Luke
          The Rabid Badger - a vBulletin Cloud customization and demonstration site.
          vBulletin 5 Documentation - Updated every Friday. Report issues here.
          vBulletin 5 API - Full / Mobile
          I am not currently available for vB Messenger Chats.

          Comment


          • #20
            Originally posted by ShyGuy82 View Post
            Zach, OR....there was another option for your developers. Have a combined primary key in the NODE table (I'm assuming it's called node). RecordId, ContentTypeId. This way you can easily map old Ids in the new system with this setup without storing OLD ids altogether. The only difference with this setup is that you no longer have auto-generated keys (you have to get Max(recordid) from node where contetypeid = X). But since new requirements for vB5 is MySql 5, they could use stored procedures, which cache sql statements a lot better than running them dynamically.
            Aside from stored procedures, we're pretty much doing it like this. Stored procedures would be nice in the future though.
            Translations provided by Google.

            Wayne Luke
            The Rabid Badger - a vBulletin Cloud customization and demonstration site.
            vBulletin 5 Documentation - Updated every Friday. Report issues here.
            vBulletin 5 API - Full / Mobile
            I am not currently available for vB Messenger Chats.

            Comment


            • #21
              So - the heart of every forum - threads and posts - get renumbered.
              And their URLs change.
              And the redirect to the new ones is 302, Temporarily Moved.

              No way we're ever upgrading.
              You don't mess with my URLs, the backbone of my website.
              Be considerate to your users. Open links in the same window.

              Comment


              • #22
                Originally posted by Zachery View Post
                Okay,

                So a quick run down, is that in order to transition the system into the new db schema the new key ids don't really match their old counter parts.
                We had things like postid, threadid, blogid, groupid, socialgroupmesageid, pmid, forumid, etc. these can't be carried over 1:1 into the new schema because of the schema.
                We keep these old ids mapped properly. So if someone comes in via showthread.php?t=X or p=Y or forumdispay.php?f=Z they get redirected to the proper item in the new system.


                Am I making more sense now?
                Yes, this is completely logical. Except for the fact that part of the remapping can be avoided. Threads are by far the most linked to, so keeping that ID, would at least reduce the chance of issues and reduce the need for redirects for threads.
                I buy 420 forums

                Comment


                • #23
                  Originally posted by Wayne Luke View Post
                  Aside from stored procedures, we're pretty much doing it like this. Stored procedures would be nice in the future though.
                  Wayne, I really really not trying to be negative but given the requirements for vB5 why wouldn't developers do that from the get go? Not only its a lot faster than dynamic sql, it also makes code maintenance so much easier. If something doesn't work right with the query - change it in one place, recompile stored proc and you are done. Stored procs also remove spaghetti string concatenation in code, it's a lot easier to read. They also give you full control of conditional coding, loops, cursors etc.

                  About old links - I understand that old links would still work because you guys store old Ids during the upgrade. The problem with this is that you store bloated records (they are unneeded). This extra column takes 4 bytes, with 1 million posts, that's extra 40MB. Multiply that number of records of ALL CONTENT and you get a lot of used space in the database (dead space). I haven't seen the code yet but I really hope vB doesn't store old Ids in the same node table. If they do, this bloated size will continue to grow even for new records. They would store 0 (zero) as old id and still take 4 bytes. Someone with larger boards than mine will increase their database size even more dramatically.
                  Speed up your member list page by at least 5x (4.x.x)

                  http://nicknameregister.com/files/20...0/ShyGuy82.jpg

                  Comment


                  • #24
                    Even if vB emitted the correct HTTP code (301 instead of 302), can you imagine what such a huge amount of redirects does to the search engine rankings?
                    If 99% pages change their URL, the website can kiss its whole Google ranking goodbye for at least three months. A lot of them will most likely never return to their old positions.
                    This is an unbelievable decision.

                    I don't care that vB5 decided to go all Reddit on its database and use one huge "things" table. The URLs should, no, must not change.
                    Be considerate to your users. Open links in the same window.

                    Comment


                    • #25
                      Retal I've written a post in other thread (don't remember where) where I've explained that 301 is perfectly fine for google. I've done exactly that 2 weeks ago. Google reindexed all my links within a week (hundreds of thousands of them). Some old links still do show up in search results but it didn't hurt my ranking one bit, I would actually argue that I increased my search traffic since then.
                      Speed up your member list page by at least 5x (4.x.x)

                      http://nicknameregister.com/files/20...0/ShyGuy82.jpg

                      Comment


                      • #26
                        Originally posted by ShyGuy82 View Post
                        Retal I've written a post in other thread (don't remember where) where I've explained that 301 is perfectly fine for google. I've done exactly that 2 weeks ago. Google reindexed all my links within a week (hundreds of thousands of them). Some old links still do show up in search results but it didn't hurt my ranking one bit, I would actually argue that I increased my search traffic since then.
                        Lucky you. I have seen numerous sites that have not had this experience. And then there is the issue of the overhead requiring you to map every single one of your posts/threads, etc. - let's say you have 500,000 posts.... what about 5 million? I avoided this entirely with VB 4. Right now, moving to any other software is the same as moving to VB 5. I'm not altogether confident of VB 5's direction at the moment.
                        My law forum, lawyers and legal help site

                        Comment


                        • #27
                          Originally posted by ShyGuy82 View Post
                          301 is perfectly fine for google. I've done exactly that 2 weeks ago. Google reindexed all my links within a week (hundreds of thousands of them). Some old links still do show up in search results but it didn't hurt my ranking one bit, I would actually argue that I increased my search traffic since then.
                          Even if that were true - which it isn't - are you going to let vB change your links on every major version?
                          New links when upgrading to vB5, then new links when upgrading to vB6 (provided the company survives), etc?

                          It's simply a good practice not to change the URLs and vB has done the very opposite - changed *everything*.

                          See also Cool URIs don't change.
                          Be considerate to your users. Open links in the same window.

                          Comment


                          • #28
                            I would like to be able to have the upgrade program keep the threadid the same and the URL format be the same as I currently use which is the Standard URLs that I've used for the last 10 years. Example:

                            https://www.vbulletin.com/forum/showthread.php?t=407313

                            Don't tell me it would be impossible to do this.

                            Comment


                            • #29
                              It is currently impossible to do. (because we haven't done it. I don't know how feasible it is to actually do, since there isn't a showthread.php file, i am not a modrewritefu master)

                              https://www.vbulletin.com/forum/showthread.php?t=407313

                              Would redirect to the new url format though

                              Comment


                              • #30
                                Originally posted by Zachery View Post
                                https://www.vbulletin.com/forum/showthread.php?t=407313

                                Would redirect to the new url format though
                                I will not upgrade if the threadid and postid are changed. I don't want to have to use a lookup table with millions of rows of data to convert old id's to new id's.

                                Comment

                                Related Topics

                                Collapse

                                Working...
                                X