1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Brainstorming :: Unique md5 ProductID's => Thread Creation

Discussion in 'XenForo Development Discussions' started by Niteblade, Oct 2, 2011.

  1. Niteblade

    Niteblade Member

    Because of Xenforo's active development and because Xenforo has been demonstrated to scale well, e.g., there are forums with thousands and thousands of posts that run nice and fast (just try that with Wordpress ... :) ), I am attempting to store the content of product reviews in the xF database.

    Here's a little background.

    I'm coding a product comparison and shopping script in PHP that interfaces with an external API. Part of the information that the API returns is a list of products for sale. (The product's title, md5 id, description, price, merchant, and brand are listed and returned as a PHP array for further server-side processing.) Each individual product for sale has its own md5 hash. Let me also add that it is possible to fire off a query to the API with the md5 hash as a parameter in order to grab the specific product matching the hash.

    I'm thinking of how I'm going to bridge the md5 hash for each individual product with a xF forum topic revolving around the product in question. In this manner, when someone searches for a specific item through the API search engine, relevant customer reviews are pulled from xF's database. In other words, the product's unique md5 hash relates to and pulls information from xF's database.

    I'm not asking for anyone to do this work for me, but I would appreciate being pointed in the right direction.

  2. Niteblade

    Niteblade Member

    1. Map an md5 hash value from an external php script to a particular forum thread as a new thread or as a reply to an existing thread. (Script => xF).
    2. Display/import a forum thread based upon the md5 hash value from the external script. (xF => Script)
  3. SheepCow

    SheepCow Well-Known Member

    If you have a thread_id to product_hash table, you could do any of these:

    • Allow people to associate a thread with a product when they create it, or
    • Create a thread any associate it with the product programmatically, or
    • Pretty much anything

    Once you've got that you can basically do anything you want
    Niteblade and James like this.
  4. Niteblade

    Niteblade Member

    I appreciate your reply. Thank you.

    I failed to mention that there are anywhere between 50 million - 60 million products available through the API, each of which has a unique md5 hash. In terms for performance, would the suggestion solution of a thread_id to product_hash suffer as a result?
  5. SheepCow

    SheepCow Well-Known Member

    Do you need a thread per product? Or just to create the thread when product-without-a-thread is reviewed (which you could check for by searching and finding 0 matches in the thread_id to product_hash table)?
  6. Niteblade

    Niteblade Member

    The way that I envision this working is that on the product details page, there will be a box containing relevant discussions (which are being pulled from the corresponding thread_id from the xF database). There will be a link here asking the user if he or she wishes to contribute to the existing discussion. The link will take the user to xF itself where posts and replies occur normally inside the thread. At this point, guests will be prompted to register for forum access.

    When a discussion has not been started yet on the product details page, meaning that there is no thread in xF, there will be a link displayed prompting the user to begin a discussion about the product. Should the user click on the link, they will be taken to xF itself. If the user is a guest, they will be prompted to join the forum. If the user is already a member of the forum, rather than giving the user the option to title their own thread, perhaps the thread title should just reflect the product md5 hash value? Or perhaps the thread title can be the same as the product's name? I suppose it does not matter, so long as the thread_id and the product's md5 hash are married in some database table.

    xF threads would be created on an "as-needed" basis (with the potential of 50-60 million of them being created), when users elect to create them from the product display page. (I don't want search engines to be able to follow the links to create blank threads, and I don't want the search engines to be able to access the section of the xF forum that houses all product discussions -- in order to prevent duplicate the content penalty. I believe that I can prevent guests and search engines from access certain parts of the forum with xF's permission system, though.) In addition, I want to prevent forum members from creating product discussion threads from within xF itself -- the only way that threads should be created is through the product details display page.

    In summary:
    1. Each product (50-60 million) has its own md5 hash value that will be married to xF's thread_is system. The translation between md5 and thread_id will be found in a separate database table.
    2. Guests cannot create product threads in xF through the product details page.
    3. Guests can view threads on the product details page, but they cannot access them through xF directly.
    4. Guests are prompted to participate in the discussion through a link. Clicking on the link takes them to forum registration.
    5. Registered members cannot create new product threads through xF in the node dedicated to product threads.
    6. Registered members can respond to existing product threads through xF in the node dedicated to product threads.
    7. New threads are created through the product details page alone.
    8. Threads are created on as "as-needed" basis by a human being who is a registered member of the forum on the product details page.
    I believe this covers the coding aspect that governs threads and md5 values being housed within the xF database. I'm pretty confident that I covered all aspects of the logic, however, I'm always open to hearing feedback that'll improve the logic.
    Again, thanks!

Share This Page