How hard is it to fix the Inbox notification ?

It is what it is but seems a simple fix , I've never been getting DM's other then a Thread of yours moved trashed, You have been slapped by a mod , But recently I've missed a few messages /Friends adds .

The revamp and fixing of the uploads is great ATS is rolling in the right direction . just a simple Icon number would be nice on the envelope .


Thanks !

I would like that , that one message i get every 10 year or so i missed by a few weeks.

a reply to: TheGreazel

It's True makes them more valuable aged messages !

How hard is it to fix the Inbox notification ?

As many years as it's been non-functional, I'd guess really hard.

originally posted by: nugget1

How hard is it to fix the Inbox notification ?

As many years as it's been non-functional, I'd guess really hard.

Hah! 1st thought that entered my mind

originally posted by: nugget1

How hard is it to fix the Inbox notification ?

As many years as it's been non-functional, I'd guess really hard.

Maybe, but my guess was different.

"Fix" implies it's broken, but I was wondering if maybe it's not broken, but was intentionally disabled, because it used too many server resources to keep it constantly updated. In that case, it would be really easy to just re-enable it if it was disabled.

Whether doing that still bogs down the server depends on how much traffic ATS still gets, but I would also note that server capabilities in general go up every year, so that the servers in use today on average are far more capable than the servers that were in use back when the notification was disabled or broken.

It was a nice feature for the envelope to turn white when we had a private message. Now that it no longer does that, I try to remember to check once a month or so, but that doesn't allow for a very timely response if I find someone asked me a question 3 weeks ago.

a reply to: Arbitrageur

Good response! I'm about three thousand mile from being computer savvy, so you guess makes a whole lot more sense than mine!

var messageIcon = document.getElementByClassName("icon-envelope");

// Check if there is an unread message
var hasUnreadMessage = true; // Replace this with your actual condition

// Change the color if there is an unread message
if (hasUnreadMessage) [
messageIcon.style.color = "red"; // Replace "red" with the desired color
]

originally posted by: ArMaP

The following is my opinion as a member participating in this discussion.

a reply to: AwakenWithMe

The more difficult part (and probably what was using too many resources) is to see if there are unread messages.

For example, counting how many unread messages exist for a specific member takes longer than just reading a counter that could be on a different table, like the table where the member's profile is stored, that is incremented every time a message is received and decremented every time one message is read.

Reading a specific value from a smaller table takes much less resources than counting how many records follow a specific condition (two conditions, in fact, the message state and the member id).

PS: I don't know a thing about the code or database design.

As an ATS Staff Member, I will not moderate in threads such as this where I have participated as a member.

Don't do that... databases have count methods which are pretty efficient.

SELECT COUNT([messageid]) FROM [messages] WHERE [userid] = [userid]

No reason to maintain another table.

a reply to: ArMaP

But you're not doing it for millions of records.

You're doing it for a user on login, and for notifications, you only care about the most recent and unread.

select count [messageid] from [messages] where ([userid] = [userid]) and ([isread] = 0) order by [date]

a reply to: ArMaP

OK, drop the order by then.

Select count id from messages where userid = userid and isread =0.

You're not scanning millions of rows. You're filtering out millions of rows that don't match your criteria, and databases are optimized to do that.

Allowing the database to do what its built to do is going to be more efficient than constant transactions that are just incrementing a column.

a reply to: ArMaP

When you execute your query in a db, it optimizes that query and figures out the best algorithms to use.

In other words; while you might look at a where clause and say "that's a for-loop," the database doesn't. The same way that when you look at the database, you see a table with rows... The database sees it as whatever data structure it's built around (mysql is a tree, for instance).

Most of those algorithms are built around the fact that the majority of data you're querying is not what you're looking for and can be dropped from the dataset.

I think there's an explain clause that will show what the database is planning to do for your query.

originally posted by: ArMaP
a reply to: rounda

I know all that, and I'm used to work with Microsoft's SQL Server and the SQL Management Studio, which has an option to show the execution plan of the executed command, I use it to optimize my queries precisely because what we expect, some times, is not how the database engine works.

But, regardless of that, the only way of the database engine knowing which records follow a specific condition is to look at all of them. Less records take less time.

Not really. Yes at some point a full scan needs to occur (mysql for example does a full scan after a cold start and populates the innodb buffer pool if using that engine). When its required really depends on too many factors (pk existing, how many? indexes rebuilt lately? any fks here? How often does this query occur? etc...).

Ex: select column from table where primary_key_column = val;

Mysql doesnt need to read all the data, it can actually pick any arbitrary location on disk and seek from there - of course this could actually end up being much slower than a full scan if the table is small.

Its really too many factors to make a blanket "requires looking at all".

Re: notifications, I think a good way (if we arent considering newer front end technologies where today this is likely to occur) is to normalize out the data into a seperate table. Each time a new message is sent, this table is updated.


create table Notifications - NotificationId (pk ai) MessageId (fk) Read(tinyint(1) add index) Dismissed(tinyint(1) add index)
Created(timestamp) Updated (timestamp)

Join this on your user object (or query separately) and get a count where read isnt 1 and dismissed isnt 1 (or count diff between users last login date and max(updated), likely too be slower, my DBA power level is too low)


Table is updated asynchronously when user dismisses the notification or reads the message. This should scale well. If notifications got turned off due to load then I'd imagine the backend is in a bad spot.