M.C.Crispy
United Kingdom
Basingstoke
Hampshire
flag msg tools
Avatar
mbmbmbmbmb
I was working on two Guild forum posts at the same time, one would reference the other, so to have the thread ID of the second post I created a one word post called "placeholder" and saved it. Then I referred to this thread in my first thread. When that was all done I went back and changed the title of the second post to reflect the real subject and then completed that post. Unfortunately, the title of that post still appears as "placeholder" in the forum, even though the link to the post is title correctly. What the heck is going on?

First post: Re: Next Extended Session
Second post: Game Requests for Extended Session: Jan 31, 2015 - longer/heavier games only please
Guild: Chineham Board Gamers

Update: in the Forum browser it all appears OK, it's only on the Guild "front page" that the title is wrong.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
col_w
United Kingdom
Poole
Dorset
flag msg tools
badge
Avatar
mbmbmbmbmb
It's probably cached - see what it looks like this tomorrow.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
M.C.Crispy
United Kingdom
Basingstoke
Hampshire
flag msg tools
Avatar
mbmbmbmbmb
Will do - though I created the posts last night. Why would it be cached for Guild front pages, but nowhere else (including the Guild Forum browser)?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Herb
United States
Georgia
flag msg tools
mbmbmbmbmb
Some info that is "frequently" used is cached so that the database doesn't have to do a lot of joins in the tables. This lightens the load on the server, but means that there are two copies of the data. A "primary" copy in the raw tables and a secondary copy that is stored in another database "joined." When and how the secondary copy is used would have been determined by analyzing traffic data to and from the servers.

The problem with the secondary copy is that there is so much information in BGG that the low level tasks to update the secondary copies now take days to run through a complete update.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
M.C.Crispy
United Kingdom
Basingstoke
Hampshire
flag msg tools
Avatar
mbmbmbmbmb
herace wrote:
Some info that is "frequently" used is cached so that the database doesn't have to do a lot of joins in the tables. This lightens the load on the server, but means that there are two copies of the data. A "primary" copy in the raw tables and a secondary copy that is stored in another database "joined." When and how the secondary copy is used would have been determined by analyzing traffic data to and from the servers.

The problem with the secondary copy is that there is so much information in BGG that the low level tasks to update the secondary copies now take days to run through a complete update.
Yes, I understand caching. What I'm surprised about is that the Forum Browser uses the uncached copy, but the Guild Front page uses the cached copy. If Guild front pages are low usage, then caching the content for those pages provides little benefit, whereas a Forum browser page must take significantly more of a beating and so would benefit from caching. The implementation seems to do the reverse, which is what I find odd. But then I don't know which attributes are cached and where those cached attributes are used.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Herb
United States
Georgia
flag msg tools
mbmbmbmbmb
mccrispy wrote:
herace wrote:
Some info that is "frequently" used is cached so that the database doesn't have to do a lot of joins in the tables. This lightens the load on the server, but means that there are two copies of the data. A "primary" copy in the raw tables and a secondary copy that is stored in another database "joined." When and how the secondary copy is used would have been determined by analyzing traffic data to and from the servers.

The problem with the secondary copy is that there is so much information in BGG that the low level tasks to update the secondary copies now take days to run through a complete update.
Yes, I understand caching. What I'm surprised about is that the Forum Browser uses the uncached copy, but the Guild Front page uses the cached copy. If Guild front pages are low usage, then caching the content for those pages provides little benefit, whereas a Forum browser page must take significantly more of a beating and so would benefit from caching. The implementation seems to do the reverse, which is what I find odd. But then I don't know which attributes are cached and where those cached attributes are used.


I don't have this information either, so any guess as to why that is optimal is pointless speculation.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
M.C.Crispy
United Kingdom
Basingstoke
Hampshire
flag msg tools
Avatar
mbmbmbmbmb
herace wrote:
mccrispy wrote:
herace wrote:
Some info that is "frequently" used is cached so that the database doesn't have to do a lot of joins in the tables. This lightens the load on the server, but means that there are two copies of the data. A "primary" copy in the raw tables and a secondary copy that is stored in another database "joined." When and how the secondary copy is used would have been determined by analyzing traffic data to and from the servers.

The problem with the secondary copy is that there is so much information in BGG that the low level tasks to update the secondary copies now take days to run through a complete update.
Yes, I understand caching. What I'm surprised about is that the Forum Browser uses the uncached copy, but the Guild Front page uses the cached copy. If Guild front pages are low usage, then caching the content for those pages provides little benefit, whereas a Forum browser page must take significantly more of a beating and so would benefit from caching. The implementation seems to do the reverse, which is what I find odd. But then I don't know which attributes are cached and where those cached attributes are used.


I don't have this information either, so any guess as to why that is optimal is pointless speculation.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Front Page | Welcome | Contact | Privacy Policy | Terms of Service | Advertise | Support BGG | Feeds RSS
Geekdo, BoardGameGeek, the Geekdo logo, and the BoardGameGeek logo are trademarks of BoardGameGeek, LLC.